Assembly Loading and Deployment

Assemblies are usually loaded automatically during JIT compilation, when the first type of an assembly is used in managed code. If you leave the #using "SampleLib.dll" directive as it is, but remove the line that declares the variable obj and instantiates SampleClass, no type from SampleLib is used in the code, and the SampleLib assembly will not be loaded. In this case, the output will contain only two assemblies.

When the JIT compiler decides to load a referenced assembly, it looks into the manifest of the referencing assembly. If the type SampleClass from the SampleLib assembly is used in the source code of the DumpAssemblyInfo application, the manifest of DumpAssemblyInfo.exe contains the following metadata:

.assembly extern SampleLib {

This information is just an alternative form of SampleLib's assembly name:

SampleLib, Version=, Culture=neutral, PublicKeyToken=null

When an assembly with a strong name is referenced, the assembly extern metadata also contains the PublicKeyToken:

.assembly extern SampleLib {

.publickeytoken = (65 D6 F5 D1 B5 D4 89 0E) .ver 0:0:0:0

In both cases, the path to SampleLib.dll is not contained in DumpAssemblyInfo's metadata. To determine the path, a special algorithm called assembly resolution is used.

If the referenced assembly does not have a strong name, the assembly resolver uses a simplified algorithm. This algorithm depends on the so-called application base directory. The application base directory is the directory in which the EXE file is located (unless you perform special customizations—which is outside of this chapter's scope).

The first location where the assembly resolver looks for an assembly without a strong name is the application base directory itself. If the assembly is not found there, it searches for a subdirectory of the base directory that is named after the simple name of the requested assembly. For the SampleLib assembly, the assembly resolver would try to find the assembly in a subdirectory named SampleLib.

Unless you provide extra configuration, no further subdirectories of the application base directory will be inspected by the assembly resolver. If you need to configure the assembly resolver to search for assemblies in further subdirectories of the application base directory, you can create an application configuration file as follows:

<!-- MyApplication.exe.config --> <?xml version="1.0"?> <configuration> <runtime>

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <probing privatePath="lib;bin" />

</assemblyBinding> </runtime> </configuration>

When a weakly named assembly is found, the assembly loader checks if the simple name, the Culture, and the PublicKeyToken of the found assembly match the name of the requested assembly. If this is the case, the assembly will be loaded. As mentioned previously, the version number of a weakly named assembly is not relevant for assembly loading. Even if the version number of the found DLL is lower than the requested version number, the assembly will be loaded and used.

For assemblies with a strong name, the version number is not silently ignored: you must ensure that the right version of every dependent strongly named assembly can be found. However, for strongly named assemblies, there are further deployment options.

Was this article helpful?

0 0

Post a comment