[wix-users] Bootstrapper .NET Framework prerequisite

Wed Nov 7 10:40:22 PST 2018

This here is the disconnect:

> You start the installer, it detects that .NET is missing or out of date, it installs the correct .NET version.
> It then starts your bootstrapper UI.
> At this point you have not actually installed anything yet, you just started up the installer.

With the current design of Burn that last sentence is not correct. The current design of Burn is that once you install one thing from your chain, you've installed something from Burn and thus require the ARP registration.

You are correct that one possible solution to address this design issue a new PrereqChain (or some other idea). And I do agree Burn should be able to behave more like you describe. But that is work that needs to be designed and then built into Burn. Obviously, no one has stepped up to do that.

In the meantime, I wouldn't hack around the lack of this feature by trying to manually whack at registry keys.

Finally, it is entirely possible for your bundle to be registered and find some or even none of its chained packages installed. That's a normal state to be in and the one I was saying you should support.

_____________________________________________________________
 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 9:46 AM
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

I expect I am being unclear as to why this is a bug and is written up as a bug in the system.

I added a test to see if the product is already installed because I could not find a valid way (even with providing a GUID for the product ID vs using '*') to ensure that every time I build the installer it would recognize it as the same install\same version.  After every build it be detected as absent and would of course want to install again instead of running uninstall/modify etc.

So let's simplify.  What I am trying to 'fix' with my workaround is the actual bug that is written up.

You have a simple installer using a custom bootstrapper.
The installer itself has a prerequisite to have a specified version of the .NET Framework installed.
You start the installer, it detects that .NET is missing or out of date, it installs the correct .NET version.
It then starts your bootstrapper UI.
At this point you have not actually installed anything yet, you just started up the installer.
You don't want it to try and uninstall .NET, that is a prerequisite and should just stay where it is.
The user decided they don't want to install and they click cancel.
The install did not fail, it worked as expected, nothing was wrong, it was not a failed install, there was no rollback.
You then look in programs and features and your product appears to have been installed even though the user never accepted the install.
At this point, if you have modify enabled, you can uninstall or modify, but modify has no meaning at this stage because nothing was installed.

So, what I am 'fixing' is making sure that if the user exits the installer (not because an error occurred), the erroneous 'installed' version of the product is removed from the registry.

I suppose a way to fix WiX without requiring major rework would be to add a section like <prereqchain> or something like that?  Some stuff burn would install before you get to your installer and leave alone afterwards.

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

Your BA is provided that value via Command.Resume

I don't know why you consider this state a bug. There are many ways your bundle can naturally end up in a partially installed state. As I said before, this is a normal situation your BA should handle.

The correct way to remove the registration (and the other parts you haven't found or might change) is to uninstall.
_____________________________________________________________
 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 7:05 AM
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

I have been digging through the source code and found that there is a function in core.cpp (CoreQueryRegistration) that checks the Resume value in the registry to see if the installation was resumed (I assume after a reboot or even if it just had to resume it after installing .NET Framework (no reboot).

It has the registration registry key in there, so now all I have to do is figure out what that registry key is (hopefully in a Burn variable), check the value myself and then I will know that it's a resume, so continue the install normally and if the user cancels the install, add code to delete the uninstall registry key.  Does that sound about right?

-----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 7:07 AM
To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
Cc: Vanniekerk, Tyrel (GE Healthcare) <tyrel.vanniekerk at ge.com>
Subject: EXT: Re: [wix-users] 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/

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

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

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