Namespaces and Assemblies...

There is quite a good video of this on MSDN that discusses namespaces and assemblies. Too often I have seen project/assembly overload; where for each and every namespace there is an associated assembly – where it would be simpler to create a single parent assembly at a logical root within the namespace and include all children keeping the original namespaces. There are very good reasons for these, supported by the following key points that really resonated with me within this video:

Factor functional into assemblies based on:

• Performance: There is overhead in loading each assembly - all other things being equal, the fewer assemblies an application loads the quicker the load time
• Versioning: All code in an assembly must version at the same rate
• Security: All code in an assembly has the same identity and is granted the same level of trust

Assemblies and Performance - Prefer single, large assemblies to multiple, smaller assemblies:

• Helps reduce working set of application
• Larger assemblies are easier for NGEN to optimise
• Where several assemblies are always loaded together, combine into a single assembly

Assemblies and Servicing – Ease of Use:

• Fewer DLLs are easier to use than many - easier to deliver, set up, build with, and maintain

Assembly Version Number:

• All four parts of the version matter (...)
• You can't change the revision and have binding still work
• Assemblies should use version numbers - considered part of the assembly's identity

Namespaces:

• They can span assemblies - consider moving designer or obscure types to new assembly

Let's consolidate and keep it simple ;-)