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

Wed Jun 10 08:56:10 PDT 2020

A couple clarifications:

> People make mistakes, so there must be a way to correct those mistakes.

Agreed. My recommendation is to fix the mistakes by going forward, not by trying to go backward. YMMV.

> It seems pretty arbitrary to me that KeyPath can be "no" for base installer files, but not for patch files...

Directory based Components are supported in patches but the Windows Installer does not (if my memory is correct) let you _change_ the Component's KeyPath in a patch. There are a lot of limitations what can be done via a patch in the Windows Installer. This (if my memory correct) is just one of them.

Finally, auto-generating GUIDs is quite challenging. The Windows Installer is pretty unforgiving and that is why the WiX toolset limits what can be auto-generated. You might find the fundamentals of the problem interesting: http://robmensching.com/blog/posts/2003/10/18/component-rules-101/

From: Todd Hoatson <todd.hoatson at gmail.com>
Sent: Tuesday, June 9, 2020 6:51 PM
To: Rob Mensching <rob at firegiant.com>
Subject: Re: [wix-users] Always installing a subset of files from within a patch

Thanks Rob & Jacob...

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

Apparently not.

> 2. Downgrading file versions is notoriously error prone

So are human software developers!  : /

People make mistakes, so there must be a way to correct those mistakes.

> Wouldn't a Major Upgrade MSI (not a patch) with RemoveExistingProducts scheduled early allow them to get rid of the bad and ensure serviceability going forward?

Yes, that's what we decided to do.  But please understand, I work for a non-profit with thousands of users all over the remotest parts of the world.  Poor internet service is the norm.  So the difference between distributing a base installer (259MB) vs. a patch (39.5MB) is a BIG deal.

It seems pretty arbitrary to me that KeyPath can be "no" for base installer files, but not for patch files...

Todd

On Tue, Jun 9, 2020 at 11:06 AM Rob Mensching <rob at firegiant.com<mailto:rob at firegiant.com>> wrote:
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<mailto: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<mailto:wix-users at lists.wixtoolset.org>>
Cc: Todd Hoatson <todd.hoatson at gmail.com<mailto: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<mailto:todd.hoatson at gmail.com>
www.linkedin.com/in/toddhoatson<http://www.linkedin.com/in/toddhoatson>

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

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