Using WiX to Install VB6 Binary Files

Question

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

The InstallShield project actually marks them as self-registering files. From what I read, this seems like a “bad thing” in the Windows installer world.

My question is: what should I do then? The VB6 project can change the internal GUIDs after each recompilation - and yes, I already use binary compatibility.

I used Heat to generate all registry entries and classes, but some of these entries vary from assembly to assembly. I read that Heat was not intended to be used in every assembly, but was instead used as a starting point.

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

Answer 1

One thing we played with is generally to exclude global COM registration, using COM without registration . (The main advantage we use is the ability to deploy different versions of the same application side by side in complete isolation.)

However, without registering without registering, you still have to write or generate manifest files that must be installed by the installation. Answers to a related question show that there are some tools for this.

At the same time, we also use a combination of self-registration and automatic generation of wxs with heat.exe for our old VB6 and Delphi libraries. Although you are right that heat was not originally intended for such use, it is already moving in that direction .

In any case, stable regeneration of identifiers (which was not in the initial design of heat.exe) is important only if you want to support minor updates or exchange components between applications. We will simply completely remove the previous version of the product during the update (aka main update ), so we do not need to worry about such things.

Answer 2

We have two types of components that we are developing in VB6. Hidden common components that we refer to projects and volatile components of the application that we create daily. Common components are packaged as merge modules (using WiX), while application components are mapped to application configuration components. 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 still use WiX 2.0, so we use a modified version of fat to create .wxi registry files for all the ActiveX / OCXs / EXEs DLL files that we create daily. Instead of com / typelib entries, we send the entire COM entry as a direct entry to the registry table. We focus on the outdated Windows 2.0 installer because we don’t need any new features.

We use custom actions (VC6 DLL) for some special cases - setting up MSDE, fixing the database, loading / setting up DCOM. We use an SDK platform loader that downloads instmsiX.exe and prepares the Windows installer on virgin systems (mainly 9x and NT). We use a 7-zip self-extractor to unpack bootstrapper and msi on the client machine. In some cases, we use UPX -lzma for executable files, but they do not scale very well on terminal servers where unpacked versions are reused in sessions.

Recently, we have been porting our customers to portable builds using a non-access COM server. We use our own UMMM tool to create a COM manifest without registering. SxS COM has limitations (no DCOM, no ActiveX EXE), but allows us to change assemblies while the application is running - do not reset the downtime.

Answer 3

I went the other way and defined all my objects using the interfaces that I created in IDL and compiled to input libraries (.tlb). Somewhat long winding, but this means that all GUIDs remain fixed independently.

I can embed versions of interfaces and process multiple versions of DLLs in a single file.

Disadvantages: this does not help with OCX controls, and you cannot use events that activate the tlb border. This is not a problem for me, since I usually use DLL callbacks for my callers, as they can be more efficient.

This product has been deployed to DVD for customers around the world, it is currently using the InstallShield installer, but I am also exploring the transition to WiX.