Typelib Generation and Installation with WiX

问题:

After asking about what Visual Studio does to register a COM Library, it became clear that VS did two things for COM registration:

1. Registered the COM Library
2. Creates and registers a Type Library

Visual Studio seems to do this registration using regasm.exe. For the first part (the direct COM registration) using tallow or heat (WiX 2.0 or WiX 3.0) seems to get all of the basic COM registration information correct.

However, what tallow/heat doesn't seem to do is set up a type library installation. It would be possible to create a custom action to do this with a WiX installer and regasm.exe, but invoking custom actions are not best practices when it comes to Microsoft installer based installers.

Upon further research, it looks like an msi has the ability to generate the type library upon installation. In fact, WiX seems to have direct support for it! In a file element, you can add a Typelib element. In fact, an article over here on wix has an example of filling out the TypeLib element with Interface elements.

It seems there's at least two required attributes to an Interface element:

1. Id
2. Name

Larry Osterman speaks about the other parts of the interface that need to be registered for a TypeLib in general, and this Interface entry seems to take care of the individual parts. Larry says we need to specify the ProxyStubClassId32 as "{00020424-0000-0000-C000-000000000046}", so we can easily add that.

Where to go from there and what to fill out for the various Interface elements has me stumped. I've gone ahead and added the TypeLib element to my wix file, and it successfully compiles. I'm a bit clueless as to how to set up the Interface elements though. What do we need to do to properly fill out the TypeLib element, and what apps or tools can I use to get it?

The answer below by wcoenen looks promising...I'm going to give it a shot.

Update: Posted my final solution below as an answer.

回答1:

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.

回答2:

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
   

回答3:

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!