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?

1 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.

  • 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). Apr 14, 2012 at 20:54
  • @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.
    – Oded
    Apr 15, 2012 at 6:44
  • So if I'm writing a utilities library, when should I consider new assemblies?
    – dlras2
    Apr 15, 2012 at 14:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.