[wix-users] Upgrade Variable
John Cooper
JoCooper at jackhenry.com
Wed Nov 16 06:01:23 PST 2016
Interesting. Need my project managers to settle on a feature set to make that work. Then I could probably make it work with based on number of AppPools, number of SQL instances, etc., and turn them on and off as needed.
--
John Merryweather Cooper
Senior Software Engineer -- Integration Development Group -- Enterprise Notification Service
Jack Henry & Associates, Inc.® | Lenexa, KS 66214 | Office: 913-341-3434x431050
JoCooper at jackhenry.com
-----Original Message-----
From: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org] On Behalf Of Phill Hogland
Sent: Tuesday, November 15, 2016 5:00 PM
To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
Subject: Re: [wix-users] Upgrade Variable
The e-mail below is from an external source. Please do not open attachments or click links from an unknown or suspicious origin.
For my 'basic' bundles I inject the base Model class and use a RootView.xaml and a RotViewModel.cs, very similar to the structure of the WixBA.
For some bundles which require specialized behavior, but can use the same 'look and feel' as the basic bundles, I derive a bundle tag named Model class from the base Model and inject it as my Model in MVVM.
For my bundles which need different 'options' displayed, in addition to driving a Model class, as above, my RootViewModel uses the BundleTag to set various Properties used to enable the display of additional UserControls. The RootView has these UserControls which are bound to the Properties mentioned, so that they only show when running a particular bundle. I'm currently supporting 21 bundles per release cycle with a wide variety of complexity among the bundles, using a single mba implementation.
________________________________
From: wix-users <wix-users-bounces at lists.wixtoolset.org> on behalf of John Cooper <JoCooper at jackhenry.com>
Sent: Tuesday, November 15, 2016 3:12:10 PM
To: WiX Toolset Users Mailing List
Subject: Re: [wix-users] Upgrade Variable
Ok, that sounds interesting. Because of the nature of my products, a fair amount of UI code is custom, but most of the event handlers are re-useable. (One versus two SQL instances, Feature Tree differences, etc.)
I'll have to play with it. Just hadn't thought of checking the Tag which I already have.
--
John Merryweather Cooper
Senior Software Engineer -- Integration Development Group -- Enterprise Notification Service Jack Henry & Associates, Inc.® | Lenexa, KS 66214 | Office: 913-341-3434x431050 JoCooper at jackhenry.com
-----Original Message-----
From: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org] On Behalf Of Phill Hogland
Sent: Tuesday, November 15, 2016 1:26 PM
To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
Subject: Re: [wix-users] Upgrade Variable
The e-mail below is from an external source. Please do not open attachments or click links from an unknown or suspicious origin.
I'm sure that the UpgradeCode could be used (if that is what gets passed into DetectRelatedBundleArgs e.productcode). I have not checked that and it was not obvious to me from the wix documentation when I was implementing this code, whereas e.BundleTag is clearly documented and in my mind more readable.
The more important reason that I use bundle/@tag, is based on how I structured my dependency injection. I name the BundleTag the same as my class which defines my Model (in MVVM), derived from a base model class which implements the common domain related behavior. I use a single mba dll for many bundles, and I use the BundleTag from the bootstrapperData.xml to indicate which Model and View classes should be added to my IoC for use by DI. The DI needs to be configured before the wix engine is dispatched, which is why I do not us the Burn variable to get the BundleTag in this situation. So since I start by detecting the BundleTag, and I define my Model based on it, then in places were behavior differentiates I use overridden methods in the derived Model to implement the behavior change and the View binds to properties to hide pieces of the View not related to the detected bundle.
________________________________
From: wix-users <wix-users-bounces at lists.wixtoolset.org> on behalf of John Cooper <JoCooper at jackhenry.com>
Sent: Tuesday, November 15, 2016 11:00:26 AM
To: WiX Toolset Users Mailing List
Subject: Re: [wix-users] Upgrade Variable
Good suggestion. I check for MajorUpgrade in my DetectRelatedBundle handler, and I have a Bundle at Tag set for each bundle, but I'm not checking the Tag. All my products have different upgrade codes. Other than paranoia factor, what is checking the Tag buying me?
--
John Merryweather Cooper
Senior Software Engineer -- Integration Development Group -- Enterprise Notification Service Jack Henry & Associates, Inc.® | Lenexa, KS 66214 | Office: 913-341-3434x431050 JoCooper at jackhenry.com
-----Original Message-----
From: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org] On Behalf Of Phill Hogland
Sent: Tuesday, November 15, 2016 8:18 AM
To: wix-users at lists.wixtoolset.org
Subject: Re: [wix-users] Upgrade Variable
The e-mail below is from an external source. Please do not open attachments or click links from an unknown or suspicious origin.
The way I do this is:
1) I author each bundle with a bundle/@tag .
2) In DetectRelatedBundle handler, if e.Operation is ReleatedOperation.MajorUpgrade and e.BundleTag is the tag for this bundle, then I set a property in my model to indicate that I am doing a Major Upgrade.
I have not had any reason to modify WixStandardBootstrapperApplication.cpp so I am not sure I follow that comment. If not using a custom ba, but using the WixStdBA I would look at parsing the raw command line string in a bafunctions.dll, although I have not done this for several years, and don't recall if it would lead to a solution.
________________________________
From: wix-users <wix-users-bounces at lists.wixtoolset.org> on behalf of Collin Perschon <collin.perschon at fidelissecurity.com>
Sent: Monday, November 14, 2016 6:00:36 PM
To: wix-users at lists.wixtoolset.org
Subject: [wix-users] Upgrade Variable
Hello,
I am trying to determine if my custom bootstrapper application is in a MajorUpgrade or an Install. I looked through the Burn Built-in variables and thought that maybe WixBundleAction or WixBundleInstalled would be the ticket. However they both return (5 and 0) respectively for both my install and upgrade environments. So far the only file I have modified is the WixStandardBootstrapperApplication.cpp to add a an extra options page. IE:
EULA > Options / Install
I would like it to go this way for an upgrade:
EULA > Upgrade Detected > Options / Install.
The reason is that we want to prompt the user for some information that will help make their life easier for running the application after the upgrade. It isn't required information, but it will save the user a lot of time ( and potential headaches ) if they provide it before we upgrade. I've already added an "advanced options" page, so adding a new page won't be an issue. I'm just kind of lost on how to determine if I'm in an upgrade or not.
The enum for BOOTSTRAPPER_ACTION is:
enum BOOTSTRAPPER_ACTION
{
BOOTSTRAPPER_ACTION_UNKNOWN,
BOOTSTRAPPER_ACTION_HELP,
BOOTSTRAPPER_ACTION_LAYOUT,
BOOTSTRAPPER_ACTION_UNINSTALL,
BOOTSTRAPPER_ACTION_CACHE,
BOOTSTRAPPER_ACTION_INSTALL,
BOOTSTRAPPER_ACTION_MODIFY,
BOOTSTRAPPER_ACTION_REPAIR,
BOOTSTRAPPER_ACTION_UPDATE_REPLACE,
BOOTSTRAPPER_ACTION_UPDATE_REPLACE_EMBEDDED,
};
So, I'm currently in the install. I'm wondering why I didn't get to UPDATE_REPLACE for upgrade. (Perhaps it is because I'm doing major upgrades which is uninstall / install? )
If anyone can point me in the right direction I would really appreciate it.
Thanks so much,
Collin
____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/
____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/
NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information.
Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies.
____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/
____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/
NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information.
Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies.
____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/
____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/
NOTICE: This electronic mail message and any files transmitted with it are intended
exclusively for the individual or entity to which it is addressed. The message,
together with any attachment, may contain confidential and/or privileged information.
Any unauthorized review, use, printing, saving, copying, disclosure or distribution
is strictly prohibited. If you have received this message in error, please
immediately advise the sender by reply email and delete all copies.
More information about the wix-users
mailing list