What is the impact of having namespaces in multiple DLLs?

Question

I've inherited a VB.net project that generates 2 DLLS: one for the web app, and another for the "business layer". This is for a sub-app of a larger web site. (Using VS2005).

The problem is that that something doesn't smell right with the DLL & namespace structure, and I'd like to know if there are any performance impacts.

The main web app is "Foo", and generates Foo.dll. Foo.dll contains namespace App.Foo, which contains the classes for all the pages, user controls, etc.

There's also a project "FooLib" that generates FooLib.dll. FooLib.dll also contains an App.Foo namespace, which contains a bunch of class definitions. There are a few other namespaces like App.Foo.Data, App.Foo.Logic, etc.

Is there anything wrong with this? How does the runtime find a class across multiple DLLs?

Answer 1

No there is nothing wrong with overlayed namespaces. Take a look at the .net framework itself where many namespaces are overlayed.

Answer 2

Namespaces are not present at the IL level. The runtime find a class from a pseudo fully qualified name, that is, the name of the type prefixed by its namespace.

I don't think there is a technical problem to do that, in fact the .NET Framework itself sometimes uses same namespaces accross several physical assemblies.

Namespace are not first class citizen in the .NET world, and I regret that.

Answer 3

There's nothing wrong with this, the only possible issues may be that 1) developers seeing "App.Foo.Something" may not know which assembly to look in 2) if the same name is used in both, apps compiling against (in c# at least) will get errors about ambiguous type names.

As for the runtime, types are specified by assembly and name - the namespace is just part of the typename. So the runtime will have no issue finding the type - when you compile the information about what assembly to find it in is compiled in.

Answer 4

When your program is compiled the full type name is included along with "evidence". This evidence includes the name of the assembly and versioning information. Otherwise it wouldn't know if you wanted the 1.0 or the 1.1 or the 2.0 version of the class. This same system allows it to find different classes in the same namespace in different assemblies.

As far as performance goes, there's not a huge effect. On the beneficial side it means that some of your stuff could be loaded at different times and that's usually the desired effect.

Namespaces are about packaging functionality in a way that makes it easy to find. Assemblies are about packaging functionality in a way that is efficient to load. Sometimes they're not the same.

Answer 5

No, there's nothing wrong with this.

Consider, I use a number of custom class libraries, and nearly every one of them has the following namespace structure:

.Web.UI.Controls.

Which is similar (and suggested by MS as best practice) to System.Web.UI.Controls..

The thing is that the Compiler will know that there is the right namespace in as many DLLs as you assign (it will search for it across both DLLs). The only reason I'd hesitate at making them the exact same in this way is because of possible DEVELOPER confusion. The other reason is in case each namespace has a class named the exact same thing--and this will toss an compiler error until it is resolved with a fully named Namespace declaration.

Which is part of the reason why you can Alias namespaces. Aliasing will cure both concepts. The structure for it looks like this:

using Foo.App.Foo;
using FooLib = FooLib.App.Foo;

So, if you then have a Bar class in both Foo.App.Foo and FooLib.App.Foo, to access the application version you would use:

bar x = new bar();

For the Library version you'd use:

FooLib.bar x = new FooLib.bar();