Deploying COMWin32 Applications That Use .NET Components | The .NET and COM Interoperability Handbook (Integrated .Net)


Team-Fly

	.NET and COM Interoperability Handbook, The By Alan Gordon
	Table of Contents

	Chapter Eight. Advanced COM to .NET Interop

Deploying COM/Win32 Applications That Use .NET Components

When you instantiate a .NET object from a COM client, the CLR must be able to locate the assembly that contains the .NET object's class. The CLR uses the same algorithm to locate the assembly that it would use if the object were instantiated from a managed client. The CLR first applies versioning policy to potentially change the requested version number of the assembly. The CLR then checks to see if the requested version of the assembly is already loaded into the current AppDomain. If the current version is not already loaded, the CLR searches the following in order: the GAC and then a specified CodeBase . Finally, it probes for the assembly beneath the unmanaged client application's root directory.

Note

See the section entitled "How the Runtime Locates Assemblies" in Chapter 3 for complete details on how the CLR locates assemblies.

Therefore, when you attempt to use a managed code assembly from an unmanaged client, the managed code assembly must reside in one of three places: (1) the client application's root directory (or a subdirectory beneath this root), (2) the GAC, or (3) a specified codebase. At this point, you should be familiar with options 1 and 2. When you use the Assembly Registration Tool, you can specify a codebase for the assembly using the /codebase parameter to the tool. For instance, the following command registers the assembly called myassembly.dll for use by an unmanaged client, creates and registers a type library for the assembly, and sets the codebase for the assembly equal to the location where the assembly currently resides:

 regasm myassembly.dll /codebase /tlb

The Assembly Registration Tool inserts the code base location into the registry entries that it creates for the assembly. Use the codebase during development or as a last resort. If you cannot install the assembly beneath the root directory of the unmanaged client application, you are better off using the GAC instead of specifying a codebase. The GAC supports versioning. This brings some performance benefits because the .NET runtime will verify the assembly when you install it into the GAC, and therefore the runtime does not have to verify the assembly each time an application loads it.


Team-Fly

Top