[wix-users] Always installing a subset of files from within a patch

[Rob Mensching]

I _believe_ there are two pieces of bad news (but you'll can verify because my memory of these areas is a bit foggy):

1. I don't think changing the KeyPath is supported during patching.

2. Downgrading file versions is notoriously error prone.

I don't know what the limitations are but my bet is you will be *much* better served updating the version (that reverts the bad behavior).

Going back in time is very, very, very challenging.

---
Short replies here. Complete answers here: https://www.firegiant.com/services/

-----Original Message-----
From: wix-users <wix-users-bounces at lists.wixtoolset.org> On Behalf Of Todd Hoatson via wix-users
Sent: Monday, June 8, 2020 8:18 AM
To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
Cc: Todd Hoatson <todd.hoatson at gmail.com>
Subject: [wix-users] Always installing a subset of files from within a patch

Hi,
  we have a product which uses WiX to produce its installer.  The product has a base installer for the new version, and then has patch installers for updates to that version.

  Our process for creating the installer uses heat.exe to "harvest" the relevant files, rather than manually specifying them.  For the base installer, we use the -gg option to ask heat to generate the GUIDs for the components that it identifies.  For the patch installer, this is impossible (more on that in a moment); we ask heat to defer generation of the GUIDs to compile time by placing '*' in the output file where the GUID would normally be specified.  The processes look like this:

Base Installer
  heat -> candle -> light -> signtool
  -gg

Patch Installer
  "Old" Version
    heat -> candle -> light -\
    -ag                       \
                               ---> torch -> candle -> light -> pyro -> signtool
  "New" Version               /
    heat -> candle -> light -/
    -ag

The significance of the -ag option for the GUID is that the new version needs to be compared with the old version to determine which bits have changed.  If heat generates different GUIDs for these two versions, then pyro thinks that everything has changed between the two versions, and generates a long list of errors.

Unfortunately, we had a recent mistake in our attempt to fix a bug, and this broke backward-compatibility.  We need to revert to prior versions of several DLLs in order to fix this bug.  The version numbers of these DLLs are critical to the restoration of function, so we can't create new DLLs with the prior, compatible function.

We wanted to use KeyPath="no" for these few DLLs in order to force the installation of these DLLs without looking at the version numbers.  I tried to use an XSLT transform on the call to heat to change the KeyPath value from "yes" to "no" for only these few DLLs.  However, I found that we are unable to set KeyPath="no" without also generating GUIDs immediately.

This seems like an unnecessary restriction / limitation.  Is there some way to have a small subset of files always installed, regardless of version number, in a patch installer?

Thanks for any help / suggestions you can offer!

--
Todd Hoatson
Mobile: 763-291-3312
Email:   todd.hoatson at gmail.com
www.linkedin.com/in/toddhoatson

____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/