Using WiX to install VB6 Binaries

Question

I am converting an InstallShield project to a WiX based Installer. I have a number of VB6 projects whose binaries need to be registered.

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?

Answer 1

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.