Namespaces allow for the logical grouping of related types. For example System.Web.UI relates all the types related to the web. i.e it provides classes and interfaces that helps us in building ASP.NET server controls and ASP.NET web pages that form the user interface of the web application. Similarly System.Windows.Forms namespace will contain all the classes required for a windows application. The CLR doesn’t know anything about the namespaces. When you access the type the CLR has to know the full name of the type and which assembly contains the definition of the type so that the run time can load the proper assembly. Look at the following sample code.
System.Web.UI.WebControls.TextBox mytextbox = new System.Web.UI.WebControls.TextBox();
The same code can written in a much cleaner way by “using” keyword as follows
TextBox mytextbox = new TextBox();
In the previous code example, the compiler needs to ensure that every type referenced exists and that my code is using that type in the correct way: calling methods that exist, passing the right number of arguments to these methods, ensuring that the arguments are the right type,using the method’s return value correctly, and so on. If the compiler can’t find a type with the specified name in the source files or in any referenced assemblies, it prepends the namespace names which are specified in the using statements to the type name and checks if the generated name matches an existing type. If the compiler still can’t find a match, it prepends System.Web.UI.WebControls , to the type’s name. The using directives shown earlier allow me to simply type TextBox in my code—the compiler automatically expands the references to System.Web.UI.WebControls. I’m sure you can easily imagine how much typing this saves as well as how much cleaner your code is to read.When checking for a type’s definition, the compiler must be told which assemblies to examine the compiler will scan all of the referenced assemblies looking for the type’s definition. Once the compiler finds the proper assembly, the assembly information and the type information is emitted into the resulting managed module’s metadata. To get the assembly information, you must pass the assembly that defines any referenced types to the compiler. The C# compiler, by default, automatically looks in the MSCorLib.dll assembly even if you don’t explicitly tell it to. The MSCorLib.dll assembly contains the definitions of all of the core Framework Class Library (FCL) types, such as Object, Int32, String, and so on.Having said that most of the times we will get confused on how assemblies and namespaces relate to each other? From my experience I can tell that a namespace and an assembly aren’t necessarily related. In particular a single namespace may be implemented in multiple assemblies or a single assembly can implement various namespaces (Ex: System.Object, System.Int32, System.Text.Stringbuilder are implemented in MsCorlib.dll) To further this discussion the documentation clearly says that when we look for a type a namespace is one where the type belongs to and an assembly is one where that particular type is implemented.i.eWhen you define
Textbox namebox = new Textbox();
the “Textbox” type belongs to System.Web.UI.WebControls namespace which is implemented in System.Web.dll assembly. So in order the compiler to compile this code we need to have the System.Web.dll in the references and add the namespace at the beginning of the page.
I hope this information clarifies your confusion in differentiating namespaces and assemblies.