Assemblies in .NET

Assemblies Overview

Assemblies are a fundamental part of programming with the .NET Framework. An assembly performs the following functions:

• It contains code that the common language runtime executes. Microsoft intermediate language (MSIL) code in a portable executable (PE) file will not be executed if it does not have an associated assembly manifest. Note that each assembly can have only one entry point (that is, DllMain, WinMain, or Main).

• It forms a security boundary. An assembly is the unit at which permissions are requested and granted.

• It forms a type boundary. Every type's identity includes the name of the assembly in which it resides. A type called MyType loaded in the scope of one assembly is not the same as a type called MyType loaded in the scope of another assembly.

• It forms a reference scope boundary. The assembly's manifest contains assembly metadata that is used for resolving types and satisfying resource requests. It specifies the types and resources that are exposed outside the assembly. The manifest also enumerates other assemblies on which it depends.

• It forms a version boundary. The assembly is the smallest versionable unit in the common language runtime; all types and resources in the same assembly are versioned as a unit. The assembly's manifest describes the version dependencies you specify for any dependent assemblies.

• It forms a deployment unit. When an application starts, only the assemblies that the application initially calls must be present. Other assemblies, such as localization resources or assemblies containing utility classes, can be retrieved on demand. This allows applications to be kept simple and thin when first downloaded.

• It is the unit at which side-by-side execution is supported.

Assemblies can be static or dynamic. Static assemblies can include .NET Framework types (interfaces and classes), as well as resources for the assembly (bitmaps, JPEG files, resource files, and so on). Static assemblies are stored on disk in portable executable (PE) files. You can also use the .NET Framework to create dynamic assemblies, which are run directly from memory and are not saved to disk before execution. You can save dynamic assemblies to disk after they have executed.

There are several ways to create assemblies. You can use development tools, such as Visual Studio .NET, that you have used in the past to create .dll or .exe files. You can use tools provided in the .NET Framework SDK to create assemblies with modules created in other development environments. You can also use common language runtime APIs, such as Reflection.Emit, to create dynamic assemblies.


Assembly Benefits

Assemblies are designed to simplify application deployment and to solve versioning problems that can occur with component-based applications.

End users and developers are familiar with versioning and deployment issues that arise from today's component-based systems. Some end users have experienced the frustration of installing a new application on their computer, only to find that an existing application has suddenly stopped working. Many developers have spent countless hours trying to keep all necessary registry entries consistent in order to activate a COM class.

Many deployment problems have been solved by the use of assemblies in the .NET Framework. Because they are self- describing components that have no dependencies on registry entries, assemblies enable zero- impact application installation. They also simplify uninstalling and replicating applications.

Versioning Problems

An End to DLL Conflicts

To solve versioning problems, as well as the remaining problems that lead to DLL conflicts, the runtime uses assemblies to do the following:

• Enable developers to specify version rules between different software components.

• Provide the infrastructure to enforce versioning rules.

• Provide the infrastructure to allow multiple versions of a component to be run simultaneously (called side-by-side execution).

Assembly Names

An assembly's name is stored in metadata and has a significant impact on the assembly's scope and use by an application. A strong-named assembly has a fully qualified name that includes the assembly's name, culture, public key, and version number. The runtime uses this information to locate the assembly and differentiate it from other assemblies with the same name. For example, a strong-named assembly called myTypes could have the following fully qualified name:

"myTypes, Version=1.0.1234.0, Culture="en-US", PublicKeyToken = b77a5c561934e089c

In this example, the fully qualified name indicates that the myTypes assembly has a strong name with a public key token, has the culture value for US English, and has a version number of 1.0.1234.0.

Code that requests types in an assembly must use a fully qualified assembly name. This is called fully qualified binding. Partial binding, which specifies only an assembly name, is not permitted when referencing assemblies in the .NET Framework.

All assembly references to assemblies that make up the .NET Framework also must contain a fully qualified name of the assembly. For example, to reference the System.Data .NET Framework assembly for version 1.0 would include:

System.data, version=1.0.3300.0, Culture=neutral, PublicKeyToken = b77a5c561934e089

Note that the version corresponds to the version number of all .NET Framework assemblies that shipped with .NET Framework version 1.0. For .NET Framework assemblies, the culture value is always neutral, and the public key is the same as shown in the above example.


Assembly Contents

In general, a static assembly can consist of four elements:

• The assembly manifest, which contains assembly metadata.

• Type metadata.

• Microsoft intermediate language (MSIL) code that implements the types.

• A set of resources.

Only the assembly manifest is required, but either types or resources are needed to give the assembly any meaningful functionality.

There are several ways to group these elements in an assembly. You can group all elements in a single physical file, which is shown in the following illustration.




Assembly Location

An assembly's location determines whether the common language runtime can locate it when referenced, and can also determine whether the assembly can be shared with other assemblies. You can deploy an assembly in the following locations:

• The application's directory or subdirectories.

This is the most common location for deploying an assembly. The subdirectories of an application's root directory can be based on language or culture. If an assembly has information in the culture attribute, it must be in a subdirectory under the application directory with that culture's name.

• The global assembly cache.

This is a machine-wide code cache that is installed wherever the common language runtime is installed. In most cases, if you intend to share an assembly with multiple applications, you should deploy it into the global assembly cache.

• On an FTTP server.

An assembly deployed on an FTTP server must have a strong name; you point to the assembly in the codebase section of the application's configuration file.

Types of Assemblies

• Private
• Public / Shared
• Satellite

A private assembly is normally used by a single application, and is stored in the application's directory.

A shared assembly is normally stored in the global assembly cache, which is a repository of assemblies maintained by the .NET runtime.

Satellite assemblies are often used to deploy language-specific resources for an application. These language-specific assemblies work in side-by-side execution because the application has a separate product ID for each language and installs satellite assemblies in a language-specific subdirectory for each language.


Public / Shared Assemblies - Installing an Assembly into the Global Assembly Cache

if we want to make any public / shared assemblies, it must be strong named and deployed in Global Assembly Cache (GAC). below the find the steps to add the assembly into GAC.

Global Assembly Cache

Each computer where the common language runtime is installed has a machine - wide code cache called the global assembly cache. The global assembly cache stores assemblies specifically designated to be shared by several applications on the computer.

You should share assemblies by installing them into the global assembly cache only when you need to. As a general guideline, keep assembly dependencies private, and locate assemblies in the application directory unless sharing an assembly is explicitly required. In addition, it is not necessary to install assemblies into the global assembly cache to make them accessible to COM interop or unmanaged code.

Note There are scenarios where you explicitly do not want to install an assembly into the global assembly cache. If you place one of the assemblies that make up an application in the global assembly cache, you can no longer replicate or install the application by using the xcopy command to copy the application directory. You must move the assembly in the global assembly cache as well.

There are several ways to deploy an assembly into the global assembly cache:

• Use an installer designed to work with the global assembly cache. This is the preferred option for installing assemblies into the global assembly cache.

• Use a developer tool called the Global Assembly Cache tool (Gacutil.exe), provided by the .NET Framework SDK.

• Use Windows Explorer to drag assemblies into the cache.

Note In deployment scenarios, use Windows Installer 2.0 to install assemblies into the global assembly cache. Use Windows Explorer or the Global Assembly Cache tool only in development scenarios, because they do not provide assembly reference counting and other features provided when using the Windows Installer.

Administrators often protect the WINNT directory using an access control list (ACL) to control write and execute access. Because the global assembly cache is installed in the WINNT directory, it inherits that directory's ACL. It is recommended that only users with Administrator privileges be allowed to delete files from the global assembly cache.

Assemblies deployed in the global assembly cache must have a strong name. When an assembly is added to the global assembly cache, integrity checks are performed on all files that make up the assembly. The cache performs these integrity checks to ensure that an assembly has not been tampered with, for example, when a file has changed but the manifest does not reflect the change.

Creating and Using Strong-Named Assemblies

A strong name consists of the assembly's identity — its simple text name, version number, and culture information (if provided) — plus a public key and a digital signature. It is generated from an assembly file using the corresponding private key. (The assembly file contains the assembly manifest, which contains the names and hashes of all the files that make up the assembly.)

Remember that once you give an assembly a strong name, all assemblies that reference that assembly also have to have strong names, so that the security of the strongly named assembly is not compromised.

Note Once an assembly is created, you cannot sign it with a strong name. You can sign an assembly with a strong name only when you create it.

Strong Name Tool (Sn.exe)

The Strong Name tool helps sign assemblies with strong names. Sn.exe provides options for key management, signature generation, and signature verification.

sn [-quiet][option [parameter(s)]]

Examples

The following command creates a new, random key pair and stores it in keyPair.snk.

sn -k keyPair.snk

Signing an Assembly with a Strong Name

There are two ways to sign an assembly with a strong name:

• Using the Assembly Linker (Al.exe) provided by the .NET Framework SDK.

• Using assembly attributes to insert the strong name information in your code. You can use either the AssemblyKeyFileAttribute or the AssemblyKeyNameAttribute, depending on where the key file to be used is located.

You must have a cryptographic key pair to sign an assembly with a strong name.

To create and sign an assembly with a strong name using the Assembly Linker

At the command prompt, type the following command:

al /out:[assembly name] [module name] /keyfile:[file name]

In this command, assembly name is the name of the assembly to sign with a strong name, module name is the name of the code module used to create the assembly, and file name is the name of the container or file that contains the key pair.

The following example signs the assembly MyAssembly.dll with a strong name using the key file sgKey.snk.

al /out:MyAssembly.dll MyModule.netmodule /keyfile:sgKey.snk


To sign an assembly with a strong name using attributes

In a code module, add the AssemblyKeyFileAttribute or the AssemblyKeyNameAttribute, specifying the name of the file or container that contains the key pair to use when signing the assembly with a strong name.

The following code example uses the AssemblyKeyFileAttribute with a key file called sgKey.snk.

[Visual Basic]
Assembly:AssemblyKeyFileAttribute("sgKey.snk")
[C#]
[assembly:AssemblyKeyFileAttribute(@"..\..\sgKey.snk")]

You can also delay sign an assembly when compiling. After adding the file, compile the assembly once to take the changes.

When signing an assembly with a strong name, the Assembly Linker (Al.exe) looks for the key file relative to the current directory and to the output directory. When using command-line compilers, you can simply copy the key to the current directory containing your code modules.


To install a strong-named assembly into the global assembly cache

At the command prompt, type the following command:

gacutil -I [assembly name]

In this command, assembly name is the name of the assembly to install in the global assembly cache.

The following example installs an assembly with the file name hello.dll into the global assembly cache.

gacutil -i hello.dll


To remove an assembly from the global assembly cache

At the command prompt, type the following command:

gacutil -u [assembly name]

In this command, assembly name is the name of the assembly to remove from the global assembly cache.

The following example removes an assembly named hello.dll from the global assembly cache.

gacutil -u hello

The .NET Framework SDK also provides a Windows shell extension called the Assembly Cache Viewer (Shfusion.dll), which you can use to remove assemblies from the global assembly cache.


To view a list of the assemblies in the global assembly cache

At the command prompt, type the following command:

gacutil -l

The .NET Framework SDK also provides a Windows shell extension called the Assembly Cache Viewer (Shfusion.dll), which you can use to view the contents of global assembly cache.

posted by Vijay Kumar @ 11/16/2006 10:41:00 PM