An assembly is a fundamental building block of any .NET Framework application. For example, when you build a simple C# application, Visual Studio creates an assembly in the form of a single portable executable (PE) file, specifically an EXE or DLL.
Assemblies contain metadata that describe their own internal version number and details of all the data and object types they contain.
Assemblies are only loaded as they are required. If they are not used, they are not loaded. This means that assemblies can be an efficient way to manage resources in larger projects.
Assemblies can contain one or more modules. For example, larger projects may be planned in such a way that several individual developers work on separate modules, all coming together to create a single assembly.
Assemblies have the following properties:
Assemblies contain metadata that describe their own internal version number and details of all the data and object types they contain.
Assemblies are only loaded as they are required. If they are not used, they are not loaded. This means that assemblies can be an efficient way to manage resources in larger projects.
Assemblies can contain one or more modules. For example, larger projects may be planned in such a way that several individual developers work on separate modules, all coming together to create a single assembly.
Assemblies have the following properties:
- Assemblies are implemented as .exe or .dll files.
- You can share an assembly between applications by placing it in the Global Assembly Cache.
- Assemblies must be strong-named before they can be placed in the Global Assembly Cache.
- Assemblies are only loaded into memory if they are required.
- You can programmatically obtain information about an assembly using reflection.
- If you want to load an assembly only to inspect it, use a method such as ReflectionOnlyLoadFrom.
- You can use two versions of the same assembly in a single application.
A namespace is a logical naming scheme for types in which a simple type name, such as MyType, is preceded with a dot-separated hierarchical name.
Such a naming scheme is completely under the control of the developer. For example, types Person.FileAccess.A and Person.FileAccess.B might be logically expected to have functionality related to file access.
The .NET Framework uses a hierarchical naming scheme for grouping types into logical categories of related functionality, such as the Microsoft® ASP.NET application framework, or remoting functionality. Design tools can make use of namespaces to make it easier for developers to browse and reference types in their code.
The concept of a namespace is not related to that of an assembly. A single assembly may contain types whose hierarchical names have different namespace roots, and a logical namespace root may span multiple assemblies.
In the .NET Framework, a namespace is a logical design-time naming convenience, whereas an assembly establishes the name scope for types at run time.
Such a naming scheme is completely under the control of the developer. For example, types Person.FileAccess.A and Person.FileAccess.B might be logically expected to have functionality related to file access.
The .NET Framework uses a hierarchical naming scheme for grouping types into logical categories of related functionality, such as the Microsoft® ASP.NET application framework, or remoting functionality. Design tools can make use of namespaces to make it easier for developers to browse and reference types in their code.
The concept of a namespace is not related to that of an assembly. A single assembly may contain types whose hierarchical names have different namespace roots, and a logical namespace root may span multiple assemblies.
In the .NET Framework, a namespace is a logical design-time naming convenience, whereas an assembly establishes the name scope for types at run time.
A private assembly is used only by a single application, and is stored in that application's install directory (or a subdirectory therein). A shared assembly is one that can be referenced by more than one application. In order to share an assembly, the assembly must be explicitly built for this purpose by giving it a cryptographically strong name (referred to as a strong name). By contrast, a private assembly name need only be unique within the application that uses it.
By making a distinction between private and shared assemblies, we introduce the notion of sharing as an explicit decision. Simply by deploying private assemblies to an application directory, you can guarantee that that application will run only with the bits it was built and deployed with. References to private assemblies will only be resolved locally to the private application directory.
There are several reasons you may elect to build and use shared assemblies, such as the ability to express version policy. The fact that shared assemblies have a cryptographically strong name means that only the author of the assembly has the key to produce a new version of that assembly. Thus, if you make a policy statement that says you want to accept a new version of an assembly, you can have some confidence that version updates will be controlled and verified by the author. Otherwise, you don't have to accept them.
For locally installed applications, a shared assembly is typically explicitly installed into the global assembly cache (a local cache of assemblies maintained by the .NET Framework). Key to the version management features of the .NET Framework is that downloaded code does not affect the execution of locally installed applications. Downloaded code is put in a special download cache and is not globally available on the machine even if some of the downloaded components are built as shared assemblies.
The classes that ship with the .NET Framework are all built as shared assemblies.
By making a distinction between private and shared assemblies, we introduce the notion of sharing as an explicit decision. Simply by deploying private assemblies to an application directory, you can guarantee that that application will run only with the bits it was built and deployed with. References to private assemblies will only be resolved locally to the private application directory.
There are several reasons you may elect to build and use shared assemblies, such as the ability to express version policy. The fact that shared assemblies have a cryptographically strong name means that only the author of the assembly has the key to produce a new version of that assembly. Thus, if you make a policy statement that says you want to accept a new version of an assembly, you can have some confidence that version updates will be controlled and verified by the author. Otherwise, you don't have to accept them.
For locally installed applications, a shared assembly is typically explicitly installed into the global assembly cache (a local cache of assemblies maintained by the .NET Framework). Key to the version management features of the .NET Framework is that downloaded code does not affect the execution of locally installed applications. Downloaded code is put in a special download cache and is not globally available on the machine even if some of the downloaded components are built as shared assemblies.
The classes that ship with the .NET Framework are all built as shared assemblies.
An assembly is the primary building block of a .NET Framework application. It is a collection of functionality that is built, versioned, and deployed as a single implementation unit (as one or more files). All managed types and resources are marked either as accessible only within their implementation unit or as accessible by code outside that unit.
Assemblies are self-describing by means of their manifest, which is an integral part of every assembly.
The manifest: Establishes the assembly identity (in the form of a text name), version, culture, and digital signature (if the assembly is to be shared across applications).
Defines what files (by name and file hash) make up the assembly implementation.
Specifies the types and resources that make up the assembly, including which are exported from the assembly.
Itemizes the compile-time dependencies on other assemblies.
Specifies the set of permissions required for the assembly to run properly.
This information is used at run time to resolve references, enforce version binding policy, and validate the integrity of loaded assemblies. The runtime can determine and locate the assembly for any running object, since every type is loaded in the context of an assembly. Assemblies are also the unit at which code access security permissions are applied. The identity evidence for each assembly is considered separately when determining what permissions to grant the code it contains.
The self-describing nature of assemblies also helps makes zero-impact install and XCOPY deployment feasible.
Assemblies are self-describing by means of their manifest, which is an integral part of every assembly.
The manifest: Establishes the assembly identity (in the form of a text name), version, culture, and digital signature (if the assembly is to be shared across applications).
Defines what files (by name and file hash) make up the assembly implementation.
Specifies the types and resources that make up the assembly, including which are exported from the assembly.
Itemizes the compile-time dependencies on other assemblies.
Specifies the set of permissions required for the assembly to run properly.
This information is used at run time to resolve references, enforce version binding policy, and validate the integrity of loaded assemblies. The runtime can determine and locate the assembly for any running object, since every type is loaded in the context of an assembly. Assemblies are also the unit at which code access security permissions are applied. The identity evidence for each assembly is considered separately when determining what permissions to grant the code it contains.
The self-describing nature of assemblies also helps makes zero-impact install and XCOPY deployment feasible.
The new basic entity is called an Assembly. This is a collection of class modules presented as a single DLL or EXE file. Even though EXE files can also be called assemblies, most of the time we talk about libraries if we use this word. Assemblies are very similar to Java Archives (JAR).
Physically, assemblies are files located somewhere on disk and are per definition so-called Portable Executable (PE). Assemblies are loaded on demand. They are not loaded if not needed.
Assemblies have Metadata stored to provide version information along with a complete description of methods and types. Part of this metadata is a Manifest. The manifest includes identification information, public types and a list of other used assemblies.
Distinguish between the typical DLLs, we've already used in the times before .NET, Private Assemblies, used for single programs, and Global Assemblies shared among several applications.
Assemblies are still DLLs even if they differ from the former DLLs. In our context, there is no difference between the direct use of DLLs and Private Assemblies. Thus the direct use of DLLs is still an issue and not outdated.
Direct Use of DLLs
Source files may be compiled into DLLs instead of EXEs. Even if we link them later on to assemblies, we first compile them to normal DLLs. During EXE file compilation DLLs may be added directly. There is no obligation to create assemblies first.
Intended use by single applications. Building modules to group common functionality.
Publicly sharing functionality among different application.
Physically, assemblies are files located somewhere on disk and are per definition so-called Portable Executable (PE). Assemblies are loaded on demand. They are not loaded if not needed.
Assemblies have Metadata stored to provide version information along with a complete description of methods and types. Part of this metadata is a Manifest. The manifest includes identification information, public types and a list of other used assemblies.
Distinguish between the typical DLLs, we've already used in the times before .NET, Private Assemblies, used for single programs, and Global Assemblies shared among several applications.
Assemblies are still DLLs even if they differ from the former DLLs. In our context, there is no difference between the direct use of DLLs and Private Assemblies. Thus the direct use of DLLs is still an issue and not outdated.
Direct Use of DLLs
Source files may be compiled into DLLs instead of EXEs. Even if we link them later on to assemblies, we first compile them to normal DLLs. During EXE file compilation DLLs may be added directly. There is no obligation to create assemblies first.
- Location is specified at compile time. Usually in the same folder like the application's EXE file or in any of the sub folders.
- PATH is not checked while looking up files, neither set by Control Panel 'System' configuration nor set in a Console Window.
- Identified by name only.
- Get smaller EXE files.
- Dynamic linking, i.e. loading on demand.
Intended use by single applications. Building modules to group common functionality.
- Location is specified at compile time. Usually in the same folder like the application's EXE file or in any of the sub folders.
- PATH is not checked while looking up files, neither set by Control Panel 'System' configuration nor set in a Console Window.
- Identified by name and version if required. But only one version at a time.
- Digital signature possible to ensure that it can't be tampered.
- Get smaller EXE files.
- Dynamic linking, i.e. loading on demand.
Publicly sharing functionality among different application.
- Located in Global Assembly Cache (GAC).
- Identified by globally unique name and version.
- Digital signature to ensure that it can't be tampered.
- Get smaller EXE files.
- Dynamic linking, i.e. loading on demand.