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 level and fundamental classes in the top level namespace? Should there generally be one namespace to one assembly? Are there any pitfalls to having multiple assemblies in one namespace or multiple namespaces in one assembly. Are there any compile time/ run time penalties for multiple assemblies or very large assemblies?

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.