[wix-users] Patch Rollback Problems

[Todd Hoatson]

To answer my own question from last month (see attached e-mail, below)...

In a post prior to that, I had asked the best way to force a file to be
updated, even though it was not newer.  It turns out someone else on my
team had tried doing this before I came to this project.  If you know about
doing patches, then you are aware that you must build a .msi file
representing the already-released product, then create another .msi file
representing the new product version.  Then you must use torch.exe to
create the transform file, which is then used to build the patch.

I order to ensure that certain files were copied to the target machine even
if they were not newer, these files were intentionally left out of the .msi
file for the  already-released product.  The fact that they were present
only in the .msi for the new product version caused torch.exe to see them
as additions which must be copied to the target machine.

As it turns out, something about this little trick caused problems with the
Installed Updates list, etc.  The patch could be installed, as well as
further patches, but they could not be reliably rolled-back.

After fixing the original problem with this little hack, the hack was not
removed, and continued to be in effect for many patch builds, always
forcing the same files to be updated on the target machine, even though
there was no change in them.  After I removed this hack, I was able to
build another patch, and I was also able to successfully roll it back
without experiencing the problems described below.

So I document my experience here in case anyone else runs into a similar
problem.

The moral of this story:  if you hack a patch to force certain files to be
updated, don't forget to undo the hack before the next patch!

On Mon, Aug 17, 2020 at 1:35 PM Todd Hoatson <todd.hoatson at gmail.com> wrote:

> We have a product which has been around for years, and we are now on
> version 9.0 (about to update to 9.1).
>
> While testing the installation of 9.1, we came across some odd behavior,
> and I have now confirmed that it was also present in 9.0:
>
> I install the 9.0.103.1 base installer - OK
> I update to the 9.0.103.19 patch - OK
> I rollback* the patch to return to 9.0.103.1 - OK
> I attempt to update again to 9.0.103.19 - FAIL
>
> * Note:  for Patch rollback, I used Windows Settings > Control Panel >
> Programs & Features > Installed Updates.
>
> It looks like the second update succeeds, but after that, the version that
> displays when I run the program is 9.0.103.1, even though Patch 9.0.103.19
> is displayed in the Installed Updates list.  Also, after that second
> update, I can no longer successfully uninstall the product (the entry is
> removed from Apps and Features, but the icon is still on the desktop and
> clicking it still opens the program, because nothing has been removed from
> Program Files).  I was forced to use another tool (Revo Uninstaller) to
> actually remove it from my system.
>
> For both updates, as well as the rollback, when I watch carefully, on the
> User Account Control dialog I see:  "9.0.103.1_Installer.msi".  Is this
> how patches are supposed to work?
>
> It seems like I read something in this mailing list a while back about
> Installed Updates not being reliable, but now I can't find that...  Is that
> true?
>
> thanks,
> Todd Hoatson
> Mobile: 763-291-3312
> Email:   todd.hoatson at gmail.com
> www.linkedin.com/in/toddhoatson
>


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