Should classes from the same namespace be kept in the same assembly?

Question

For example, ISerializable and the Serializable Attribute are both in the System.Runtime.Serialization namespace, but not the assembly of the same name. On the other hand, DataContract attributes are in the namespace/assembly System.Runtime.Serialization.

This causes confusion when a class can have using System.Runtime.Serialization but still not have reference to the System.Runtime.Serialization assembly, meaning DataContract cannot be found.

Should this be avoided in practice, or is it common for namespaces to be split over multiple assemblies? What other issues should one be careful of when doing this?

Answer 1

Namespaces are units of logical grouping.

Assemblies are units of physical grouping.

That is, break things into different assemblies only if they are going to be deployed separately.

With the example you have given, one may want to use ISerializable and Serializable without dragging in DataContract, but if one does use DataContract, it logically belongs to the same place as it deals with serialization.

• Aaron Anodide: I struggled with this for an embarrassingly long time - now i'm struggling with understanding why it took me so long. Something about this fact goes counter to how people think (i take the existence of a second person to be a statistical trend here).
• Oded: @AaronAnodide - Visual Studio makes it far too easy to use projects (and thus, separate assemblies) as a namespacing mechanism. It took me a long while to understand that this is what is going on and why it is not a good thing.
• dlras2: So if I'm writing a utilities library, when should I consider new assemblies?