Should Entlib contrib use main Entlib namespace?

Topics: Development Team Discussion, User Discussion
Developer
Oct 2, 2007 at 3:14 PM
It's quite common in .NET (and the BCL) to have multiple assemblies contributing classes to the same namespace (i.e. System, System.Design, System.ComponentModel, etc etc.).
This makes it much easier to handle the imports, albeit hindering a bit the discoverability while reading the code.

Wouldn't it be better if all contrib code lived in the same entlib namespace? You just reference a new assembly, and you get new types, no need to import/using any new namespaces?
Oct 2, 2007 at 6:14 PM
one of the reasons we had MAX_PATH problems (both with the contrib and the original entlib release) is long namespaces. the namespaces are used to create temporary files for resources (based on their name) by the copiler.

i agree 100%, but i believe the implication above doesnt make this a step ahead.
Developer
Oct 2, 2007 at 7:03 PM
Everyone should run code from C:\ and get over it :p
I seldom run into MAX_PATH problems because I never use the docs&settings (User\... in Vista). All my code goes to C:\CodePlex or C:\Clarius. That also reinforces that everything on C:\ will vanish when I revamp the machine (which happens typically twice a year), which further encourages me to checkin everything I have lying there into TFS :)

So the decision to fork the namespace was based on this max_path problem? What's the EntLib solution going to be in the long run? Will you make the root namespace plain "EntLib"? (I think you should... after all, even WPF is just "PresentationCore", "PresentationFramework" etc.)

If that's the case, at the point where you make that change in the core EntLib, it should also be done on Contrib.
Editor
Oct 4, 2007 at 12:35 AM
While the MAX_PATH issues did influence the choice of namespaces (eg EntLibContrib rather than EnterpriseLibraryContrib), this is not the reason why we aren't using Microsoft.Practices.EnterpriseLibrary.

EntLibContrib != Enterprise Library. It's built by different people, has a different licence and follows different processes around testing, documentation and release. While both deliverables are valuable, we don't want people to be confused about which code belongs to which.

Tom