Ken Kopczyk

Hurdles in .NET Development

Archive for August, 2009

Creating COM Interop Assemblies with .NET 2.0

Posted by Ken on August 18, 2009

If you work with .NET long enough, sooner or later you’ll probably need to leverage older Win32 COM components. To allow the CLR managed code of .NET to communicate with the unmanaged code of COM, a “middleman” in the form of an interop assembly must be created. This can be done via Visual Studio or the Type Library Importer.

Creating an interop assembly with Visual Studio
Enter the “Add reference” dialog of your project, browse for your registered COM server and select it. Now take a look at the properties of the newly created reference. It is actually pointing to a new assembly called Interop.COMServerName.dll: If your COM server is foo.dll, the resulting assembly is called Interop.foo.dll. You will find this assembly in your bin directory after you build.

If your project uses an .snk or .pfx for strong naming, the interop assembly will also be strong named using that file.

A major limitation of this method I found was the fact that you can’t change the version number of the interop assembly. It is always 1.0.0.0. Bummer.

Creating an interop assembly with Type Library Importer
If you need more control, then you should use the Type Library Importer (tlbimp). This application is included with the .NET SDK.

Running the following command will create an interop assembly with a version number of your choosing:
Using our foo.dll example:

tlbimp foo.dll /out:Interop.foo.dll /asmversion:2.0.0.0

If you need the interop assembly strongly named, you can do that also. If you are using an .snk, use the following:

tlbimp foo.dll /out:Interop.foo.dll /asmversion:2.0.0.0 /keyfile:MyKey.snk

If you are using a .pfx for strong naming, it’s a bit trickier. You will also need to leverage the Strong Name Tool (sn) to create a keycontainer:

echo Prompts you for .pfx password
sn -i MyKey.pfx KeyContainerName

tlbimp foo.dll /out:Interop.foo.dll /asmversion:2.0.0.0 /keycontainer:KeyContainerName

echo Housecleaning.  Removes the key container from memory.
sn -d KeyContainerName

Now add it as a reference and you’re good to go!

Advertisements

Posted in .NET SDK, COM Interop, Visual Studio | Tagged: , , , , | Leave a Comment »

Referencing GAC Assemblies With Visual Studio 2005

Posted by Ken on August 15, 2009

In Visual Studio 2005, adding an assembly reference is straight-forward and trivial, that is, unless the assembly you are trying to reference only exists in the GAC. There are a number of tabs in the Add Reference dialog, but they browse assemblies that are all located in standard directories.

Global Assembly Cache
The GAC is special because it allows a pc to store multiple versions of the same .NET assembly. This is made possible by strong naming. More importantly, it provides a centralized location for .NET assemblies that need to be shared across multiple applications.

When viewing the GAC via the Windows shell, you go here: C:\Windows\Assembly. However, the Explorer-like UI actually represents an aggregate of files and folders. Windows is just trying to make it look nice and user friendly for us.

Tricking Visual Studio
To trick Visual Studio into referencing a GAC assembly, you can do the following:
1.) Reference a copy of the assembly that is located outside of the GAC via the Add Reference dialog. You can throw a copy on your Desktop and then reference it from there. It doesn’t matter what the file’s location is.
2.) Install the assembly into the GAC. There are a number of ways to do this. The easiest way is to use the “Microsoft .NET Framework 2.0 Configuration” app. You can find it by going to Control Panel –> Administrative Tools. Once in the app, click “Manage the Assembly Cache” and then “Add an Assembly to the Assembly Cache.”
3.) Delete the assembly file that you referenced in step 1. Go into Visual Studio and refresh the project. The path of the reference should have automatically changed over to its GAC location (C:\Windows\assembly\…).
4.) You may want to set the reference’s “Copy Local” property to False so that the build does not produce a copy of the GAC assembly in the bin folder (to avoid confusion). In doing so, you can be confident that your app is in fact hitting the GAC!

Posted in Visual Studio | Tagged: , | 7 Comments »