In Visul Studio's Object Browser, we can see that many namespaces such as System, System.Collections, System.IO have are located in a single assembly mscorlib.dll.
I'm wondering how they are separated in multiple assemblies in:
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework
I mean, we have all these namespaces as an individual DLL (e.g. System.Collections.dll) and we also have mscorlib.dll too.
An assembly can contain many types. Those types can have any namespace name. There is no hard correlation between the assembly name and the name space names that the types in the assembly use. There is no namespace named "mscorlib" in the .NET Framework for example. Namespaces are simply used to logically group types into sets.
It works the other way around too, although much less common, types with the same namespace can live in different assemblies. For example, System.String lives in mscorlib.dll, System.Uri lives in System.dll. This is not something you ever deeply worry about, it is the job of the compiler to figure out what assembly a types live in. It does this by reading the metadata in a reference assembly, it tells the compiler what types are available. You do care about it a little bit, sometimes you need to add a reference assembly so the compiler knows about the types it contains. Usually prompted by getting a compiler error ("are you missing an assembly reference?") and you looking in the MSDN Library.
Reference assemblies used to be simply a copy of the assemblies in the GAC, stored in c:\windows\microsoft.net\framework. Although it was common to get a security or bugfix update that made the copy in the GAC different from the reference assembly. Which is the point of reference assemblies, they isolate you from changes in the runtime assemblies.
That changed in .NET 4.0, the reference assemblies there are very different from the ones in the GAC. They just contain the metadata, the part that the compiler cares about, but no code at all. This isolates the changes in the runtime assemblies even stronger, Microsoft used this to ship several updates to .NET 4.0. Largely unnoticed to most programmers, like it should be, .NET Framework versions 4.01, 4.02 and 4.03 slip-streamed onto their computers without them noticing it and without that breaking their programs. Unlike some accidents in earlier versions, the case of the added WaitHandle.WaitOne(Int32) overload was notorious. Added in .NET 2 SP2 and breaking programs when they ran on a machine that didn't have SP2 installed. Pure DLL Hell.
And it enabled the notion of having different sets of reference assemblies. Especially used heavily in .NET 4.5 with the addition of support for WinRT, the api for Windows Store and Phone. You now have dozens of reference assembly sets. They only expose the types and methods that are supported on the target platform. Down to the basics, String.Copy() is supported in a desktop program but not in a Silverlight, Store or Phone app. So when you target one of those then the compiler sees a String type declaration that is missing the method. Helping you to avoid writing code that cannot run in a browser or phone.
Which is what System.Collections.dll is all about. It is one of those shim assemblies, it doesn't contain any code at all. It isolates the platform differences, the .NET 1.x collection classes were removed, just wasting space on the precious storage of a phone or slowing the download of Silverlight. At runtime, the CLR sees the [TypeForwarded] attribute on the class. Which says, "it actually lives in mscorlib.dll, go look over there".
In C# namespaces can span multiple assemblies, and reversely one assembly can contain multiple namespaces.
You can easily create this yourself.
// Project.Domain.dll
namespace Project.Domain
{
}
namespace Project.Validation
{
}
// Project.Services.dll
namespace Project.Validation
{
}
Having said that, it's rarely a good idea to do so. The rules and requirements for the framework are a bit different than for a LOB Application.
Stick with the guidelines and Visual Studio defaults (namespaces following the folder structure) unless you have very good reasons to do something else.
