Typelib Generation and Installation with WiX

Here's the lazy man's way of solving this problem: Use heat from WiX 3.0.

If you have a type library generated automatically and installed via regasm, heat can take the .tlb as an argument in

heat file c:\my\path\to\my.tlb -out tlb.wxs

It will generate all the typelib and interface elements you need to register. This won't solve the problem of needing to know them ahead of time, and it won't solve the problem of GUIDs changing when the version of the assembly changes (even if the interface doesn't - which is the only time you're supposed to change it) but it will get you partway there.

The following trick can help with harvesting any registry changes and turning them into a wxs file, including the typelib element you're after.

1. First, bring your registry back in a state where the type library was not registered:

   c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\regasm.exe /tlb /u mylib.dll

2. Export this clean state of the registry to hklm-before.reg:

   c:\WINDOWS\system32\reg.exe export HKLM hklm-before.reg

3. Register the type library again:

   c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\regasm.exe /tlb mylib.dll

4. Export the new state of the registry to hklm-after.reg:

   c:\WINDOWS\system32\reg.exe export HKLM hklm-after.reg

5. Now we have two text files, hklm-before.reg and hklm-after.reg. Create a diff.reg file which only holds the relevant differences between these. You can find the differences easily with a diffing tool. I like to use the diff tool included in TortoiseSVN since I already use that every day. (WinDiff doesn't seem to work well in this case because of text-encoding issues.)

6. We can now convert diff.reg into a .wxs by calling heat.exe with the reg command. (Requires wix 3.5 or newer.)

   heat reg diff.reg -out typelib.wxs

It looks like to register a Type library, the best way would be to generate your own IDL or ODL file, which will contain your GUIDs. The Typelibs generated directly from the Assembly are [i]dependent[/i] on the assembly version numbers : the GUIDs are generated based on that information, even if the interface hasn't changed. Visual Studio uses regasm to register and generate the typelib. Underneath that, it uses RegisterTypeLib, a win32 call. Using the typelib element seems to do something similar. No good.

However! Creating the type library by hand is painful. It is possible to get those GUIDs another way: digging them out of the typelib and creating the elements yourself.

Larry Osterman has the information that's needed: there's certain registry keys that need to be set. You can do those with the Registry table (and in Wix3, that means RegistryValue elements.) The trick here is getting the GUIDs: any old GUID will not work. Normally, getting the GUIDs is simply a matter of looking in the IDL for your library (you wrote your own IDL, right? :) ).

If you didn't write an IDL or ODL file to compile into a typelib, they still exist, in the file. Microsoft provides several handy tools: LoadTypeLibEx and the ITypeLib interface. With these interfaces, you can browse the type library and get all sorts of information. How do we browse the library?

I simply took a look at how Regasm did it! A quick dissassemble later, and we find that regasm is written in C# too. Glory day. I started up a project, and with a few using statements and a PInvoke later, we have:

using System.Runtime.InteropServices;          // for struct marshaling using System.Runtime.InteropServices.ComTypes; // for the ITypeLib + related types// TYPELIBATTR lives in two places: Interop and ComTypes, but the one// in Interop is deprecated.using TYPELIBATTR = System.Runtime.InteropServices.ComTypes.TYPELIBATTR; /// <summary>/// The registry kind enumeration for LoadTypeLibEx.  This must be made/// here, since it doesn't exist anywhere else in C# afaik.  This is found/// here: http://msdn.microsoft.com/en-us/library/ms221159.aspx/// </summary>enum REGKIND{    REGKIND_DEFAULT,    REGKIND_REGISTER,    REGKIND_NONE}// and this is how we get the library.[DllImport("oleaut32.dll", CharSet = CharSet.Unicode, PreserveSig = false)]  private static extern void LoadTypeLibEx(string strTypeLibName, REGKIND regKind, out ITypeLib TypeLib);

Whew! Once we have this out, we have to navigate the structure. This is interacting with unmanaged resources, so get ready to be Marshaling stuff around.

ITypeLib lib = null;LoadTypeLibEx(Value, REGKIND.REGKIND_NONE, out lib);IntPtr libInfoPtr = IntPtr.Zero;lib.GetLibAttr(out libInfoPtr);TYPELIBATTR libInfo =     (TYPELIBATTR) Marshal.PtrToStructure(libInfoPtr, typeof(TYPELIBATTR));int typeCount = lib.GetTypeInfoCount();for (int i = 0; i < typeCount; ++i){    ITypeInfo info;    lib.GetTypeInfo(i, out info);    IntPtr typeDescrPtr = IntPtr.Zero;    info.GetTypeAttr(out typeDescrPtr);    TYPELIBATTR type =        (TYPELIBATTR)Marshal.PtrToStructure(typeDescrPtr, typeof(TYPELIBATTR));    // get GUID, other info from the specific type}lib.ReleaseTLibAttr(libInfoPtr);libInfoPtr = IntPtr.Zero;

Whew. So, you have to write some code to extract the information. Once you do, you have to fill that information into Registy Entries, as specified By Larry Osterman.

Of course, you could avoid that step by simply writing your own IDL file to begin with. The choice in pain: it's up to you!