- Code Distribution: An Old Problem
- Creating a C# Assembly
- Using an Assembly in a C# Client Program
- Adding to the Assembly Code
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Adding to the Assembly Code
We've got the basic assembly in place, as well as its client application. Now you can add more code to the assembly as required, and then access that code from the client application by adding more code to the client application. If you prefer, you can instead create a new assembly—a useful approach if a team of developers is creating assembly code. The model is flexible and provides good separation of concerns "out of the box."
It's time to look a little more deeply at the assembly technology. Things have advanced quite a bit since the early days of DLLs! Let's close the client application and reopen the class library project.
Examining Assembly Properties
Once the class library project is open, choose Project > ClassLibrary1 Properties, and you should see something similar to Figure 2.
)
Figure 2 The class library properties.
Notice in Figure 2 that the namespace for the class library is listed along with other details, such as the version of the .NET Framework. Click the Assembly Information button, and you'll get more specific details related to the class library, as shown in Figure 3.
)
Figure 3 More assembly details.
Figure 3 illustrates the depth of information that can be embedded inside an assembly. It's possible to insert a product description, versioning details, and a globally unique identifier (GUID). The purpose of the GUID is to try to ensure that the assembly is unique inside the .NET world. In addition, you can specify a language (the spoken variety, not the programming language) as part of localizing the assembly for a specific geographic region. This type of information is known as metadata, and it helps in fully defining the various elements of your .NET software.
In addition, you can specify whether you want the class library contents to be visible to legacy COM software. Try changing the assembly version to 1.0.0.2 and clicking OK. Then choose File > Save All and rebuild the solution. Finally, right-click the DLL file in Explorer, and you should see something like Figure 4.
)
Figure 4 Disk properties.
Notice that the assembly version matches the one you used in Figure 3. There are other tools you can use to look inside your assemblies; for example, the command-line utility ildasm.exe. Let's examine that option next.
More Assembly Details
You can look inside a completely constructed assembly by using the command-line tool ildasm.exe. To see what you can do with this utility, open the file called ClassLibrary1.dll inside the project bin/Release folder with the following command:
ildasm ClassLibrary1.dll
You should see something like Figure 5.
)
Figure 5 The ildasm.exe tool in action.
Again, the version number is 1.0.0.2, per your earlier change. Click the plus sign to the left of ClassLibrary1 and then click the plus sign to the left of the expanded ClassLibrary1.Class1 definition. The constituent elements of Class1 are now visible, as shown in Figure 6.
)
Figure 6 The internals of the assembly.
Double-click the symbol next to dumpPlatformDetails : void() and you'll see the results in Figure 7—the common intermediate language (CIL) into which the original C# code has been translated.
)
Figure 7 The dumpPlatformDetails() method's CIL code.
The listing in Figure 7 represents the common language into which the C# code is translated. Before this code can run on the .NET platform, it has to be translated by a just-in-time (JIT) compiler into executable code. Happily, this translation happens automatically, without any input from you! Some of the details of Figure 7 are nonetheless interesting; for instance, notice that the owning assembly is indicated for all the symbols. An example is the method System.Environment::get_NewLine(); this method is owned by the mscorlib.dll assembly.