views:

22

answers:

1

Hi. 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!

A: 

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.

Christopher Painter
I completely take your point, but my approach is dictated by customer requirements. The situation I have dictates that I make the process as simple and as automatic as possible. I need to produce a template install project that can be easily replicated over many projects and used by **inexperienced hobbyist programmers**. Telling them to hand-edit their COM registration will end in failure. The Wix learning curve is massive and I can't inflict that on my "customers". So, pros and cons aside, the question stands - unless someone comes up with a better solution.
Tim Long
You might have a chance if this was an iPhone but on Windows it'll never happen. Installs are complicated because the underlying platform and technology stacks are complicated. Running an Install Wizard is easy, writing one isn't. Most developers hate working on installs because it's hard and boring. If anyone could have abstracted it away with an easy button, it would have already been done.
Christopher Painter

related questions