tags:

views:

2590

answers:

3

So I found this example on registering DLLs: http://blogs.msdn.com/robmen/archive/2004/04/28/122491.aspx

and WiX complains about the "AssemblyRegisterComInterop" attribute. I removed that and changed the "Assembly" attribute to win32 and it says I need to specify the AssemblyManifest attribute, but I don't know what to put there.

+6  A: 

The easiest way (and Rob M will rant and rave about how this is wrong) is just to use SelfRegCost=1 on the File tag for the DLL.

This is wrong because we should be explicitly controlling the registration of the DLL. not allowing it just to run arbitrary code via DllRegisterServer. The theory being that a DLL should do nothing beyond putting the appropriate entries in the registry when DllRegisterServer is called. Unfortunately, a lot of of them do more than that, so self-registration might be the only way to get your install to work.

It's also wrong because that means the Windows installation system doesn't know anything about those registry keys, and what should and shouldn't be there. That means repairing won't work, and possibly un-installation won't clean up properly.. etc.

Otherwise, you can generate the appropriate WiX code by pointing heat.exe at your DLL, and integrating it's output into your current WiX project. You'll get a variety of Class, ProgID, TypeLib, and Registry tags. You may need to manually edit that output to get it to compile.

Hope that helps.

Troy Howard
So basically copy/paste the output from heat.exe and change the appropriate paths etc?
Davy8
I like to put the wxs that heat created into a fragment that the main wxs references to. What was the options you passed to heat, that didn't register the dll.
CheGueVerra
I usually have to move the class and progid tags into the file tag, and possibly edit some of the registry keys. Specifically, if the DLL is a .NET DLL, you'll need to provide unique ids for the registry keys that reference mscoree.dll or you will get collisions with the auto-generated ones.
Troy Howard
i usually run heat like this: heat file -gg -sfrag "C:\path\to\file.dll" -o myfile.wxs ... then include the generated wxs file in a votive project, modify it, and reference the root component from the "main" wxs for the msi/merge module via componentref, or componentgroupref.
Troy Howard
For my build process I've automated the hand editing with customized scripts. I suggest you do the same... ;)
Troy Howard
+3  A: 

It isn't just me that will rant and rave about how SelfReg is evil. The MSI SDK gives you a list of 7 reasons why not to use SelfReg: http://msdn.microsoft.com/en-us/library/aa371608.aspx.

Example:

<Component Id="Component" Guid="*">
    <File Source="ComServer.dll">
        <Class Id="PUT-CLSID-HERE" Context="InprocServer32" ThreadingModel="apartment" Description="Your server description">
            <ProgId Id="Your.Server.1" Description="Your ProgId description">
                <ProgId Id="Your.Server" Description="Your ProgId description" />
            </ProgId>
        </Class>

        <Class Id="PUT-PROXY-CLSID-HERE" Context="InprocServer32" ThreadingModel="both" Description="Your server Proxies, assuming you have them">
            <Interface Id="PUT-INTERFACEID-HERE" Name="IInterface1" />
            <Interface Id="PUT-INTERFACEID-HERE" Name="IInterface2" />
            <Interface Id="PUT-INTERFACEID-HERE" Name="IInterface3" />
            <Interface Id="PUT-INTERFACEID-HERE" Name="IInterface4" />
        </Class>
    </File>
</Component>

Ultimately, Troy's answer is all correct.

Rob Mensching
+1  A: 

You could try to use the heat.exe program, and then reference the fragment in your wix code.

 heat.exe file <filename> -out <output wxs file>

As in:

 heat.exe file my.dll -out my.wxs
Adam Tegen