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!