Question

I'm using the Wix 3.5 Votive (visual studio integration) to author an installer for some COM objects.

In Votive, setting a project reference pulls in the binaries from that project and automatically generates the Wix source at compile time. This is absolutely great, it is DRY and means I don't have to constantly update the Wix XML. The fragment that Votive generates looks like this:

<Fragment>
    <DirectoryRef Id="INSTALLLOCATION">
        <Component Id="cmpBCE83EAB1AAF2230E306A7325EE7EA11" Guid="*">
            <File Id="fil61D40E7D1A1D0A60C27CE6960FED2B0B" Source="$(var.My.Assembly.TargetDir)\My.Assembly.dll" />
        </Component>
    </DirectoryRef>
</Fragment>

It does the same for the source files, documents and satellites, none of which I am using. However, what it doesn't do is generate the registry enties for COM registration (the assembly is marked as 'COM Visible' and 'Register for COM Interop' but Votive doesn't seem to have a mechanism to deal with that.

Behind the scenes, Votive is calling Heat.exe to harvest all this stuff, and invoking Heat on the assembly spits out a file with a bunch of <Class .../> and <RegistryValue .../> entries, which is exactly what's needed to do the COM registration. So sure enough, Heat can generate this stuff and it would be simple to do this once and edit the output into the Wix project. But, that violates the DRY principle and requires keeping the Wix project in step with the source code manually. For reasons that are somewhat tangential, I would prefer to have Votive/MSBuild do this automatically, each time the solution is built.

I'm not an MSBuild expert by any means, and I'm on a massive learning curve with Wix, Votive and MSBuild. It's taken me several days to get thus far. So, my question is this: Is there a straightforward way to have Votive/MSBuild generate this COM registration stuff each time the solution is built? I'd anticipate that for each referenced project, if the 'Register for COM Interop' option is set, then Votive/MSBuild would generate COM registration stuff for that project's output assembly. Has anyone accomplished that and, if so, can you give me a helping hand please, before my brain turns to jelly!

Was it helpful?

Solution

I don't believe any of this should be done as it takes away from the change control / deterministic behavior that I like to see in my installers. I want to know every single file / resource in the install was explicitly put into the installer and that it doesn't float in by magic. I want to explicitly harvest and author my COM metadata so that I know it's right. When you do "COM Extract at Build" ( InstallShield terminology ) the process can fail for any number of reasons and then you end up with a seemingly good build with a bad install that won't deploy properly. You can quote the DRY prinicipal but over in this domain the rules apply a little differently.

OTHER TIPS

It seems that as of Wix 3.0 (at least), it is unable to generate the COM interop elements if the library is compiled on a network drive. I've discovered the same behavior when compiling with .NET 2.0, or .NET 4.0. Switching back to building off a local drive (eg, C: ) this problem goes away for .NET 2.0 and .NET 4.0 assemblies.

I've yet to find a good workaround other than making sure it's on a local drive. :(

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top