Nbsp;   Building an Assembly That References a Strongly Named Assembly

Whenever you build an assembly, the assembly will have references to other strongly named assem- blies. This is true because System.Object is defined in MSCorLib.dll, which is strongly named. How- ever, it’s likely that an assembly will reference types in other strongly named assemblies published either by Microsoft, a third party, or your own organization. In Chapter 2, I showed you how to use CSC.exe’s /reference compiler switch to specify the assembly file names you want to reference. If the file name is a full path, CSC.exe loads the specified file and uses its metadata information to build the assembly. As mentioned in Chapter 2, if you specify a file name without a path, CSC.exe attempts to find the assembly by looking in the following directories (in order of their presentation here):

1.Working directory.

2.The directory that contains the CSC.exe file itself. This directory also contains the CLR DLLs.

3.Any directories specified using the /lib compiler switch.

4.Any directories specified using the LIB environment variable.

So if you’re building an assembly that references Microsoft’s System.Drawing.dll, you can specify the /reference:System.Drawing.dll switch when invoking CSC.exe. The compiler will examine the directories shown earlier and will find the System.Drawing.dll file in the directory that contains the CSC.exe file itself, which is the same directory that contains the DLLs for the version of the CLR the compiler is tied to. Even though this is the directory where the assembly is found at compile time, this isn’t the directory where the assembly will be loaded from at run time.

You see, when you install the .NET Framework, two copies of Microsoft’s assembly files are actually installed. One set is installed into the compiler/CLR directory, and another set is installed into a GAC subdirectory. The files in the compiler/CLR directory exist so that you can easily build your assembly, whereas the copies in the GAC exist so that they can be loaded at run time.

The reason that CSC.exe doesn’t look in the GAC for referenced assemblies is that you’d have to know the path to the assembly file and the structure of the GAC is undocumented. Alterna- tively, CSC.exe could allow you to specify a still long but slightly nicer-looking string, such as “System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a.” Both of these solutions were deemed worse than having the assembly files installed twice on the user’s hard drive.

In addition, the assemblies in the compiler/CLR directory are machine agnostic. That is, these as- semblies contain only metadata in them. Because the IL code is not required at build time, this direc- tory does not have to contain x86, x64, and ARM versions of an assembly. The assemblies in the GAC contain metadata and IL code because the code is needed only at run time. And, because the code can be fine-tuned for a specific CPU architecture, the GAC allows multiple copies of an assembly to reside within it; each copy is located under a different subdirectory for each CPU architecture.

Date: 2016-03-03; view: 657