Home/ Questions/Q 593883
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T15:53:35+00:00

I am converting an InstallShield project to a WiX based Installer. I have a

  • 0

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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0