Gallery

Assembling assemblies

Posted on 17 Jan 2006 at 16:25

Thomas Lee looks at what .NET assemblies are made up from and shows you how to make them

[MSH] C:\demo>csc /t:library maths.cs

Microsoft (R) Visual C# 2005 Compiler version 8.00.50215.44

for Microsoft (R) Windows (R) 2005 Framework version 2.0.50215

Copyright (C) Microsoft Corporation 2001-2005. All rights reserved.

[MSH] C:\demo>csc /r:maths.dll client.cs

Microsoft (R) Visual C# 2005 Compiler version 8.00.50215.44

for Microsoft (R) Windows (R) 2005 Framework version 2.0.50215

Copyright (C) Microsoft Corporation 2001-2005. All rights reserved.

[MSH] C:\demo>ls

Directory: FileSystem::C:\demo

Mode LastWriteTime Length Name

---- ------------- ------ ----

-a--- 12/2/2005 2:23 PM 309 client.cs

-a--- 12/4/2005 5:15 PM 3584 Client.exe

-a--- 12/2/2005 2:38 PM 153 maths.cs

-a--- 12/4/2005 5:15 PM 3584 maths.dll

By compiling both programs, you've just created two assemblies: client.exe and maths.dll. If you run client.exe, you'll see something like this:

[MSH] C:\demo>./client

In Client.exe

In Add in Maths.dll

2 + 2 = 4

Building and using .NET assemblies isn't much different from using non-managed applications - .NET applications run like all the other applications you're used to, although you have to have the CLR loaded, both to compile and run the program. Also, when you run the client program, the Framework needs to be able to find and load maths.dll. I'll come back to the issue of how .NET finds components later in this article.

The Manifest

A key feature of assemblies is that they're self-describing, through the use of a manifest. The manifest is a component of every assembly's metadata, and every assembly has a manifest that describes precisely what that assembly contains. In the example above, there are two assemblies (client.exe and maths.dll) and therefore two manifests. For maths.dll, the manifest would show the exported maths class, while for client.exe the manifest shows the Main routine is exported. The CLR uses the information in an assembly's manifest to resolve references, to enforce binding to specific versions of an assembly and to ensure the integrity of a loaded assembly. The manifest contains at least the following:

Assembly name: a text filename.

Version number: expressed by four digits (for example, 1.2.3.4) that represent the major version number, minor version number, revision and build numbers.

Culture: information about what language (aka culture) this assembly supports. This is used to create language-specific versions of an assembly, known as satellite assemblies.

Strong name information: the public key, if this assembly has been given a strong name.

File list: a list of the files contained in the assembly and a hash of each file (to detect changes to the files contained in the assembly).

Type information: metadata about the contents of the assembly. This information is used by the CLR at runtime to map references to a component onto the file containing that component (for example, mapping the reference to the maths class within client.exe to the file maths.dll).

Information on referenced assemblies: a list of other assemblies used by this assembly.

To look inside an assembly and view its manifest, use ILDASM, as shown in Figure 2. As you can see, the manifest lists the external assemblies the client program uses (for example, Mscorlib and maths.dll) and defines the content of the assembly, including the version of the assembly and details of the actual runtime module (client.exe). The manifest for the maths DLL looks similar, although since it's a DLL called by the client it contains no reference to the client, but it does contain a definition of the Maths class contained in maths.dll.