C# Namespaces and Assemblies Best Practice

Question

C#: are there any guidelines, best practices when it comes to dividing a solution up into namespaces and assemblies? Should namespaces normally be nested, with the most low

Answer 1

C#: are there any guidelines, best practices when it comes to dividing a solution up into name-spaces and assemblies?

For guidelines for namespaces, read the framework design guidelines.

For assemblies: an assembly is by definition the smallest independently versionable unit of self-describing shippable functionality in .NET. Are there parts of your software that you intend to ship or version independently of each other? Then they should be in different assemblies.

Should name spaces normally be nested, with the most low level and fundamental classes in the top level name space?

Not necessarily, no.

Namespaces should be designed so that it is easy for users to discover and understand the types contained in those namespaces. Maybe you should ask your users what they think.

Should there generally be one name-space to one assembly?

Not necessarily, no.

Are their any pitfalls to having multiple assemblies in one name-space or multiple name-spaces in one assembly.

Not particularly, no.

Are there any compile time / run time penalties for multiple assemblies or very large assemblies?

Not that I'm aware of.

Answer 2

To follow up on what Eric Lippert said:

Assembly Names

It is traditional for nearly all code in a assembly to live in a single namespace and sub-namespaces, with the assembly named after the namespace.

For example, if I was given an assembly with the file name Contoso.PartnerPortal.Services.dll, the assembly's short name would traditionally be Contoso.PartnerPortal.Services, and I would expect the bulk of the code to live in the Contoso.PartnerPortal.Services namespace (and sub-namespaces).

However not all classes in the Contoso.PartnerPortal.Services namespace will necessarily live in the Contoso.PartnerPortal.Services.dll assembly. If a Contoso.PartnerPortal.dll assembly exists it may well have some classes in the Contoso.PartnerPortal.Services namespace too.

One common use of this is with interfaces. If the interfaces live in Contoso.PartnerPortal.dll then code in that assembly can use the interface without referencing the Contoso.PartnerPortal.Services.dll. This is important, since Contoso.PartnerPortal.Services.dll (which will implement the interfaces) will likely need to reference Contoso.PartnerPortal.dll and circular assembly references are best avoided.

Number/Size of Assemblies

Assemblies that are excessively large may make compilation take longer than necessary. This is because the compilers have not had support for incremental compilation in quite a long time. Thus an entire module must be compiled as a unit. Since multi-module assemblies are not frequently used this basically implies that you must compile a whole assembly at once.

If you split a large assembly into several smaller ones, only the changed assembly and those that reference will get recompiled. That saves some time.

On the other extreme having over 600 assemblies in one application (I work on such a monster in my day job) has its own set of problems. For example, the shadow copy feature of ASP.net has had performance issues working with that many assemblies (keep in mind that this is in addition to the large number of assemblies created when ASP.net compiles the aspx and ascx files).

Answer 3

Namespaces are just fancy way of splitting full class names for user's convenience. So there are no compile/run-time penalties or gains for using namespaces.

Splitting objects into assemblies will have impact on run-time and compile time, also it is unlikely to be high if you don't go with very large number of assemblies. Note that it is not possible to predict what you get gains or slowness without actual measurements for your particular case.

You should divide your project into assemblies based on your logical (i.e. by subsystems)/technical(i.e. due to component versioning) needs and than verify if performance is acceptable. If not you'll need to figure out where problems are before blaming it on number of assemblies.