Using WiX to install VB6 Binaries

I am converting an InstallShield project to a WiX based Installer. I have a number of VB6 projects whose binaries need to be r开发者_开发百科egistered.

The InstallShield project actually marks these as self-registering files. From what I have read this seems to be a "Bad Thing" in the Windows Installer world.

My question is, what should I be doing then? A VB6 project could have its internal GUIDs change after each recompile - and yes I'm already using Binary Compatibility.

I've used Heat to generate all the Registry and Class entries, but some of these entries change from build to build. I've read that Heat wasn't designed to be used every build, but instead to be used as a starting point.

What are others doing to deal with VB6 and WiX registration?

We have two types of components we develop in VB6. Latent common components that we reference across projects and volatile application components that we build daily. The common components are packed as merge modules (using WiX) while the application components map to components of the application setup. This is a snippet of our main .wxs file

<Component Id="MyFile15.ocx" Guid="YOURGUID-BCB7-451C-B07D-D205AEAE1EB9" >
    <File Id="MyFile15.ocx" Name="MyFile15.ocx" LongName="MyFile15.ocx" KeyPath="yes" src="$(var.SrcAppBinnPath)\MyFile15.ocx" DiskId="1" />
    <?include Registry_MyFile15.wxi ?>
</Component>

We are still using WiX 2.0 so we are using a tweaked version of tallow to produce the registry .wxi files for all the ActiveX DLLs/OCXs/EXEs we are building daily. Instead of com/typelib entries we are shipping all of the COM registration as direct registry table entries. We are targeting legacy Windows Installer 2.0 because we dont need any of the newer features.

We are using custom actions (VC6 DLLs) for some special cases -- MSDE setup, database patching, DCOM download/setup. We are using a Platform SDK bootstrapper that downloads instmsiX.exe and prepares Windows Installer on virgin systems (mostly 9x and NTs). We are using 7-zip self-extractor to unpack bootstrapper and msi on client machine. In some cases we are using UPX --lzma on executables but these do not scale very well on Terminal Servers where the non-packed versions are reused across sessions.

Lately we've been migrating our clients to portable builds using reg-free COM. We are using our in-house UMMM tool to produce registration-free COM manifests. SxS COM has limitations (no DCOM, no ActiveX EXEs) but allows us to change builds while the application is live -- no reinstall downtime.

One thing we've been toying with is eliminating global COM registration altogether by using registration-free COM. (The main advantage we are after is the ability to deploy different versions of the same application side by side in complete isolation.)

However, with registration-free COM you still have to write or generate the manifest files that need to be deployed by the setup. The answers to the linked question show that there are some tools to help with that.

In the mean time, we also still use a mix of self-registration and automatic wxs generation with heat.exe for our old VB6 and Delphi libraries. While you are right that heat was not initially designed to be used like that, it has been moving in that direction for a while now.

In any case, stable regeneration of identifiers (which is what was missing in the initial design of heat.exe) is only important if you want to support minor upgrades or share components between applications. We just completely uninstall the previous version of the product during an upgrade (aka a major upgrade), so we don't need to worry about such things.

edit: Since writing this answer in 2010, I've learned a thing or two about windows installer. I no longer believe that a major upgrade frees you from the need for stable GUIDs. Component GUIDs should stay stable as much as possible between in-place upgrades. Major upgrades don't always have the same end result as uninstalling+reinstalling.

I went a different route and defined all my objects using interfaces I created in IDL and compiled to type libraries(.tlb). A slightly long winded approach but it means all the GUIDs remain fixed regardless.

I am able to impliment versions of the interfaces and handle multiple versions of the dll in the same file.

Drawbacks are, this doesn't help with OCX controls and you can't use events accros the tlb boundary. This is not an issue for me as I generally use callbacks from DLL's to their callers as they can be more efficient.

This product is deployed on DVD to clients around the world, currently using an InstallShield installer but I am investigating moving to WiX as well.