I am getting very confused between Namespaces and Assemblies. Are
System.Web Namespaces or Assemblies?
I have noticed these are called namespaces and at the same time they are present in
GAC_32 folder. So what exactly are they?
System.Data is a namespace,
System.Data.DLL (the file) is an assembly.
A namespace is a logical grouping of types (mostly to avoid name collisions). An assembly can contain types in multiple namespaces (
System.DLL contains a few…), and a single namespace can be spread across assemblies (e.g.
Namespace is a logical grouping of classes belongs to same functionality. So
System.Data are namespaces
MSDN describe it as:
Namespaces are heavily used in C# programming in two ways. First, the .NET Framework uses namespaces to organize its many classes Secondly, declaring your own namespaces can help control the scope of class and method names in larger programming projects.
Assembly is chunk of (precompiled) code that can be executed by the .NET runtime environment. It contains one or more than one Namespaces. A .NET program consists of one or more assemblies.
System.Data.dll are assemblies.
MSDN describe it as:
Assemblies are the building blocks of .NET Framework applications; they form the fundamental unit of deployment, version control, reuse, activation scoping, and security permissions. An assembly is a collection of types and resources that are built to work together and form a logical unit of functionality. An assembly provides the common language runtime with the information it needs to be aware of type implementations. To the runtime, a type does not exist outside the context of an assembly.
An assembly provides a fundamental unit of physical code grouping.It is an Output Unit.
It is a unit of Deployment & a unit of versioning. Assemblies contain MSIL code.
A namespace provides a fundamental unit of logical code grouping.It is a Collection of names where in each name is Unique.They form the logical boundary for a Group of classes.Namespace must be specified in Project-Properties.
They are namespaces.Assemblies contains more than one namespace.For Example:
System.dll contains these namespaces (and more):
Also one namespace might contain nested namespaces.They are just logical names to organize the code.Just be aware, a
DLL files are assemblies that contains namespace(s).
GAC is Global Assembly Cache. According to MSDN:
The global assembly cache stores assemblies specifically designated to be shared by several applications on the computer.
So commonly used assemblies stored in the
GAC and therefore you don’t need to copy all assembly files to your project directory that you are referencing from your project.The assemblies stored in the
GAC are Strong-Named assemblies.Normally when you add a reference to an assembly from your project that is not
Strong-Named a copy of your
.dll file will be created on your
bin\Debug folder..If you wish you can make your assembly (class library project for example) Strong-Named.See: How to: Sign an Assembly with a Strong Name
The file that you see in GAC is
System.Data.dll that is an assembly and that contains namespaces including
System.Data. If you view the Reference properties in Visual studio then you will see:
Later if you right click on the reference and select view in object browser you will see namespaces in that particular assembly.
- Assembly is stored as an .EXE or .DLL files.
- Namespace is a way of grouping type names and reducing the chance of name collisions.
An assembly contains a collection of types (for example l’assembly System contains many namespaces included System, System.IO, ecc).
Usually, the name of assembly is the same of a namespace that it contains but not always.
Other example of assemblies and namespaces.
Assembly 1 (CoreAssembly.DLL)
Contains namespaces Namespace1.subnamespace1
Assembly 2 (ExtensionCoreAssembly.DLL)
Contains namespaces Namespace1.subnamespace1
It is possible use name of assembly that contains different namespaces and extend an existing assembly with an other assembly by this technique.
An assembly is a collection of types and resources that forms a logical unit of functionality. All types in the .NET Framework must exist in assemblies; the common language runtime does not support types outside of assemblies. Each time you create a Microsoft Windows® Application, Windows Service, Class Library, or other application with Visual Basic .NET, you’re building a single assembly. Each assembly is stored as an .exe or .dll file.
Note Although it’s technically possible to create assemblies that span multiple files, you’re not likely to use this technology in most situations.
Another way to organize your Visual Basic .NET code is through the use of namespaces. Namespaces are not a replacement for assemblies, but a second organizational method that complements assemblies. Namespaces are a way of grouping type names and reducing the chance of name collisions. A namespace can contain both other namespaces and types. The full name of a type includes the combination of namespaces that contain that type.
Others have given very good and detailed answers to this question. But I want to point out that when you’re not sure, you can look on MSDN. The MSDN library explains very clearly and simply the namespace and assembly in which any given type resides. It even says the name of the file
(in System.Data.dll) so there is no ambiguity.
As @amdluigi says, “Usually, the name of assembly is the same as a namespace that it contains but not always”.
There is a screenshot above of System.Data.dll in the Object Browser in Studio. It’s an excellent example to explore the issues here. Note that most of the namespaces contained within the assembly are System.Data or a sub-namespace of System.Data.
In general, it is a good practice for assembly names to be related to the namespaces within them. Notice that when Studio first creates a project to build an assembly, one of the project properties is a default namespace. At the start, Studio gives default namespace the same name as the project itself. If you ever choose to rename a project, do consider changing its default namespace as well.
There are two extra namespaces: Microsoft.SqlServer is understandable. Some SQL Server types that they didn’t want to package in a separate assembly.
But what’s with System.Xml???? There is a System.Xml.dll assembly. Why is this namespace showing up in System.Data.dll as well?
Notice that an assembly can reopen a namespace and add more to it – that’s exactly what System.Data.dll is doing with the System.Xml namespace.
The reason is that namespaces have zero performance implications, but assemblies very much do. If you have 1000 classes with substantial amounts of code, you don’t want one assembly with a very large memory footprint. Neither do you want 1000 assemblies each with one class. Any assembly needs to be loaded into memory before its contents can be executed. You want an assembly to contain a reasonable number of interrelated classes, so once your application has loaded an assembly to obtain one of its classes, it gets other classes the application is likely to need for free. Granularity is important: not too big, not too small, just right.
Notice that System.Data.dll reopens System.Xml and adds exactly one class: XmlDataDocument. It happens that this class is used to interpret relational data as an XML document. If your application is just using XML, it won’t need this class. If your application deals with relational data, it might. So while XmlDataDocument inherits from XmlDocument and is in the System.Xml namespace, it’s packaged in the System.Data.dll assembly.
All this is particularly important if you have a background with Java, where there is only one concept, the package. In .NET there are two, the assembly and the namespace. The two are orthogonal. An assembly can obviously contain more than one namespace. An assembly can reopen a namespace and add more to it – in other words, the types in a namespace may span more than one assembly.