Request for a "Proper" namespace.

May 20, 2014 at 7:19 PM
Even though it might be something really trivial, I would suggest to change the namespace of this library to follow the guidelines mentioned in the Names of Namespaces page. It doesn't change the quality of the product, and yet it just looks better! :-)
May 21, 2014 at 2:31 PM
It's a good idea, but would be a breaking change.

What namespace do you suggest?
May 21, 2014 at 2:47 PM
The name of the dll, excel.dll, has also caused problem for us. We have had to rebuild the Excel Data Reader under a new name (ExcelDataReader.dll) in order to avoid conflicts with another excel.dll from another third-party provider.

I think that ExcelDataReader would be a good name for both the namespace and the dll.
May 21, 2014 at 2:53 PM
I see in your profile that you're CTO of Release Mobile. If you developed that working there, you could use that as a Prefix. In my case, most projects I ever do are not linked to my employer so I use the name of a fake company I one day want to register. So in your case, for this product, I would go with
[YourFictiveCompanyName].ExcelDataReader (under which there would be .core, .Exceptions and .Log)

Yes, it is indeed a breaking change, but you could suggest people to :
  • If they had a using statement replace any "using Excel;" with "using Excel = YourFictiveCompanyName.ExcelDataReader;"
  • If they did't have a using statement (and used Excel.[One of your classes]) to add "using Excel = YourFictiveCompanyName.ExcelDataReader;"
However, with all that said, wether or not you do it is not a big deal, it doesn't change the fact that I like your library :-P
May 21, 2014 at 2:56 PM
DanielRousseau wrote:
I think that ExcelDataReader would be a good name for both the namespace and the dll.
The namespace should contain a prefix before the product itself. I found this library when I was about to develop something I would have called [MyEmployer].ExcelFileReader, but without the prefix, a clash might happen too easily, imo.
May 21, 2014 at 2:59 PM
That all makes sense.
It wouldn't be right to use my company name because I didn't create the library, just taken over supporting it. I guess something like ExcelTools.ExcelDataReader would do.