[wix-users] Bootstrapper .NET Framework prerequisite

Wed Nov 7 10:29:18 PST 2018

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.