[wix-users] Bootstrapper .NET Framework prerequisite

Thu Nov 8 14:08:47 PST 2018

Production builds I had assumed would always be built by a Build server.  If you don't have one and you are deploying to the wild, then you should setup some tasks to handle the versioning of the builds and store those changes in your SCM.  For anything WiX related, I always inject the build via a msbuild property, that is then passed to the WiX authoring via DefineConstants. Ex:

<PropertyGroup>
    <Release Condition="'$(Release)' == '' ">1</Release> <!-- Default it to 1...  Could just as easily throw an error, or run a custom task to read it from a file on disk -->
    <DefineConstants>
      $(DefineConstants);
      Release=$(Release);
    </DefineConstants>

    <DefineConstants Condition="'$(UpgradeCode_X_Y)' != ''">
      $(DefineConstants);
      UpgradeCode_X_Y=$(UpgradeCode_X_Y);
    </DefineConstants>
</PropertyGroup>

And used in Wix via the $(var.Release) syntax.

If this is more a problem with your internal development, create a Debug/Release and/or Ship configuration for your builds.  Use different sequences for each configuration, as well as different GUID's for the key identifiers (UpgradeCode, ProductCode, etc), and differing install folders for the MSI payloads.

-----Original Message-----
From: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org] On Behalf Of Vanniekerk, Tyrel (GE Healthcare) via wix-users
Sent: Wednesday, November 7, 2018 1:31 PM
To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
Cc: Vanniekerk, Tyrel (GE Healthcare) <tyrel.vanniekerk at ge.com>
Subject: Re: [wix-users] Bootstrapper .NET Framework prerequisite

Ok, several people answered the last email, thanks a lot guys, so I will just answer in this one email.

I am sure I don't understand everything as well as I should, so this is a learning experience for me, so thanks again for all the constructive help.

I will go research the OnDetectRelatedBundle function, have not heard of that one yet.
Jackob said something about using the version build number etc.  Seems like something that would be worth looking at, I am just not sure how to inject the build number into a regular build in Visual Studio.  I suppose if you did it from a build server you could use the number Jenkins gives you, check out the files, update the version number etc.
I added code to check for the Resume registry key and that seems to work.  Now if you click on Modify and it's not really installed, it just starts the regular UI.  The case where a user cancels the install leaves you with the opportunity to find and click on Modify in the features list, so by making sure it get's handled that seems to work.  I do need to confirm that the Resume registry key gets set to 0 after a successful install though, that might throw a spanner in the works again.
As for the installers, I have some prerequisites like .NET and the Visual C++ runtimes that get installed, but those don't get uninstalled.  I have not checked what would happen during the modify mode if someone had uninstalled one of those if it would reinstall.  Currently I have another hack in place, probably because I have not figured out the correct way to do things, sorry, to set the installer to repair mode when I run modify in one of my installers.  I needed it to run all the custom steps again and without setting the mode to repair, it was not running those.  Could be my conditions were wrong?  I might have to revisit that.

This used to be an InstallShield installer, but after they wanted to rip us for something ridiculous like $75K to update the licenses for a product that still has many of the same bugs that existed in InstallShield 7 (From early 2000's I think), it's way overpriced.  With that installer though the prerequisites were handled as a pre part of the install, which would then allow the actual installer to continue.  That probably leading to some of the confusion in trying to figure out how WiX works.

Thanks,
Tyrel

-----Original Message-----
From: Rob Mensching <rob at firegiant.com>
Sent: Wednesday, November 7, 2018 12:45 PM
To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>; Hoover, Jacob <Jacob.Hoover at greenheck.com>
Cc: Vanniekerk, Tyrel (GE Healthcare) <tyrel.vanniekerk at ge.com>
Subject: EXT: RE: Bootstrapper .NET Framework prerequisite

1. I wouldn't. You can do what you want with IBootstrapperApplication.OnDetectRelatedBundle()

2. As noted in previous email, from Burn's point of view the bundle is installed.

3. What would you show if something manually removed some or all your bundled MSI packages? This is a state you can be in. Decide what you want to show users.

_____________________________________________________________
 Short replies here. Complete answers over there: http://www.firegiant.com/

-----Original Message-----
From: wix-users <wix-users-bounces at lists.wixtoolset.org> On Behalf Of Vanniekerk, Tyrel (GE Healthcare) via wix-users
Sent: Wednesday, November 7, 2018 10:29 AM
To: Hoover, Jacob <Jacob.Hoover at greenheck.com>; WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
Cc: Vanniekerk, Tyrel (GE Healthcare) <tyrel.vanniekerk at ge.com>
Subject: Re: [wix-users] Bootstrapper .NET Framework prerequisite

I see your point about the prerequisites, but of course when you uninstall your application it does not revert to the state it was before the install started.  Those prerequisites have their own uninstallers etc.

And you are probably correct on the same but different bit.  That's why I added the check to search the registry for the bundle upgrade code.  If I find the registry key and the state is marked as DetectedAbsent (currently there is only one version of this installer, first one, so no upgrade yet) I show an error message telling the user to first uninstall the older build.  This should only happen in house as we would only release one version of this to the public and for the next release of course it would then recognize it as an upgrade because the version number would have changed.

So maybe I don't understand and this behavior has confused those running the installer.

For a different approach that flows with how WiX is supposed to be used, would you mind suggesting how I should approach the following:
1. User installs a new build of the installer with an older build currently installed.  Just remove that check and assume these people should be savvy enough to uninstall the old build first?
2. After installing .NET Framework and the installer shows in the list, is there a way to disable modify mode until the product is actually installed?
3. Should I just add a check when deciding what to show in the UI that if the product shows as if it's installed, but the resume field is not 0, then run the regular UI?

Thanks,
Tyrel

-----Original Message-----
From: Hoover, Jacob <Jacob.Hoover at greenheck.com>
Sent: Wednesday, November 7, 2018 11:55 AM
To: Vanniekerk, Tyrel (GE Healthcare) <tyrel.vanniekerk at ge.com>; WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
Subject: EXT: RE: Bootstrapper .NET Framework prerequisite

By definition, if pre-requisites were installed then machine state has been modified and the installer must be registered in order to provide it the opportunity to remove them if the install is removed.

The GUID changes because each build is unique.

What is the use case that you have that requires you to re-use a version across multiple builds of an installer? "Older but same version" seems like an oxymoron to me.

-----Original Message-----
From: Vanniekerk, Tyrel (GE Healthcare) [mailto:tyrel.vanniekerk at ge.com]
Sent: Wednesday, November 7, 2018 11:49 AM
To: Hoover, Jacob <Jacob.Hoover at greenheck.com>; WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
Subject: RE: Bootstrapper .NET Framework prerequisite

I have added an additional check to also check the resume flag.  If I could figure out how to make sure the install GUID does not change for every build that would remove the need to check for an older but same version of my installer.  I explained in a response to Rob that I am trying to make sure the installer does not end up showing as if it's installed when the installer never was run (just prerequisites were installed).

-----Original Message-----
From: Hoover, Jacob <Jacob.Hoover at greenheck.com>
Sent: Wednesday, November 7, 2018 10:49 AM
To: Vanniekerk, Tyrel (GE Healthcare) <tyrel.vanniekerk at ge.com>; WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
Subject: EXT: RE: Bootstrapper .NET Framework prerequisite

Why do you insist on "fixing WiX" when it seems like this is a check you added that is broken? Messing around with WiX registration as opposed to skipping your check seems like a backwards approach to me.  If you can detect when you need to remove the registration, you could just as easily disable your check (under the condition) and leave the WiX internals alone.

-----Original Message-----
From: Vanniekerk, Tyrel (GE Healthcare) [mailto:tyrel.vanniekerk at ge.com]
Sent: Wednesday, November 7, 2018 7:07 AM
To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
Cc: Hoover, Jacob <Jacob.Hoover at greenheck.com>
Subject: RE: Bootstrapper .NET Framework prerequisite

Well, I was asking what that event is that I should be looking at to undo what the burn did.  What happens is that my code checks to see if it finds a previous install of the product (Every time you build it creates a new GUID, so to prevent people from installing the product twice, I added that check).  Regardless of that, if the user decides to cancel after installing the .NET framework (And it does not cause a reboot on Server 2012 R2 for instance because 4.5 is pre-installed with the OS), then the product still shows as installed.  I would need to detect this event and remove it before exiting the installer.

I get it might be too much of a pain to fix it currently in WiX, I am just trying to figure out a good workaround.  I assume everyone using a custom bootstrapper has been burned (no pun intended 😉) by this bug.

-----Original Message-----
From: wix-users <wix-users-bounces at lists.wixtoolset.org> On Behalf Of Hoover, Jacob via wix-users
Sent: Tuesday, November 6, 2018 4:29 PM
To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
Cc: Hoover, Jacob <Jacob.Hoover at greenheck.com>
Subject: EXT: Re: [wix-users] Bootstrapper .NET Framework prerequisite

When 4.6.2 is installed, I assume it requests a reboot.  Since the bundle is modifying machine state, I would expect it to be in ARP, as well to have a run once key set to resume the install post reboot.  "causing the installer to fail" isn't descriptive enough to try to help, but odds are your BA isn't responding properly to a callback.

-----Original Message-----
From: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org] On Behalf Of Rob Mensching via wix-users
Sent: Tuesday, November 6, 2018 4:09 PM
To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
Cc: Rob Mensching <rob at firegiant.com>
Subject: Re: [wix-users] Bootstrapper .NET Framework prerequisite

Burn shouldn't fail if already in ARP. Your bundle should be able to install/repair or uninstall if left over in ARP. That (plus the fact that fixing the underlying issue is very tricky) is why the bug is low priority.

If your BA can't handle that state, it should.

_____________________________________________________________
 Short replies here. Complete answers over there: http://www.firegiant.com/

-----Original Message-----
From: wix-users <wix-users-bounces at lists.wixtoolset.org> On Behalf Of Vanniekerk, Tyrel (GE Healthcare) via wix-users
Sent: Tuesday, November 6, 2018 1:53 PM
To: wix-users at lists.wixtoolset.org
Cc: Vanniekerk, Tyrel (GE Healthcare) <tyrel.vanniekerk at ge.com>
Subject: [wix-users] Bootstrapper .NET Framework prerequisite

Hi,

Does anyone have some sample code how to "uninstall" your product after Burn has installed the .NET requirement?  I need to remove the registry key or something.  I know there is an old bug written up for this, but I have not seen any workarounds.  I have a .NET custom UI (C# WPF) that uses .NET Framework 4.6.2.  The bootstrapper correctly installs .NET when it's not installed, but then of course it adds itself to the Programs and Features list, causing the installer to fail.  I assume there's an event before Apply or something where I could check that Burn has installed .NET and at that point remove the registry key?

Thanks,
Tyrel

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

____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/
NOTE: This email was received from an external source. Please use caution when opening links or attachments in the message.

____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/
NOTE: This email was received from an external source. Please use caution when opening links or attachments in the message.
NOTE: This email was received from an external source. Please use caution when opening links or attachments in the message.

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

____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/
NOTE: This email was received from an external source. Please use caution when opening links or attachments in the message.