Re: [WiX-users] Bootstrapper Upgrade Detection
Any answer to this? Greg Beaty greg.bea...@gmail.com On Tue, Sep 18, 2012 at 1:00 PM, Neil Sleightholm n...@x2systems.comwrote: This is what I tried, in OnDetectRelatedBundle() save the operation. In OnPlanRelatedBundle() if the saved operation == BOOTSTRAPPER_RELATED_OPERATION_NONE (which from previous emails I believe indicates that the version matches) then set *pRequestedState = BOOTSTRAPPER_REQUEST_STATE_ABSENT. This didn't work and caused the setup to go into an infinite loop launching itself again and again. Does my code look correct? Neil -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 17 September 2012 18:39 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bootstrapper Upgrade Detection You should be able to request ABSENT for the OnPlanRelatedBundle() of the bundle that has the same version. The default is NONE so it stays. On Mon, Sep 17, 2012 at 10:03 AM, Neil Sleightholm n...@x2systems.com wrote: The BootstrapperApplication can override the default logic to do whichever you want. However, the wixstdba does not, so you get the default behavior of the engine. If you have time I'd be interested to know how, I have looked at this and as far as I can tell it is baked in to the Engine and I couldn't find any way to override it. Neil -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 17 September 2012 17:28 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bootstrapper Upgrade Detection The default upgrade logic in the Burn engine does not block and does not upgrade bundles with the same version. That is pretty arguably wrong (and is the bug Neil is referring to). smile/ The BootstrapperApplication can override the default logic to do whichever you want. However, the wixstdba does not, so you get the default behavior of the engine. Most likely, if you continue to rebuild the Bundle but keep the version the same, you have multiple bundles registered on your machine. Go to ProgramsFeatures (aka: ARP) and remove them all. Package reference counting with all those Bundles still installed will likely be very confusing. smile/ -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching http://RobMensching.com LLC -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bootstrapper Upgrade Detection
Heh, heh, yeah, you'll go into an infinite loop if the two equal bundles keep upgrading each other. I bet you ended up with thousands of burn processes running trying to upgrade each other. Heh. You probably need to throw in the relationType provided from the Command line to make sure you don't start another upgrade when you are doing an upgrade. On Fri, Sep 21, 2012 at 7:23 AM, Gregory Beaty greg.bea...@gmail.comwrote: Any answer to this? Greg Beaty greg.bea...@gmail.com On Tue, Sep 18, 2012 at 1:00 PM, Neil Sleightholm n...@x2systems.com wrote: This is what I tried, in OnDetectRelatedBundle() save the operation. In OnPlanRelatedBundle() if the saved operation == BOOTSTRAPPER_RELATED_OPERATION_NONE (which from previous emails I believe indicates that the version matches) then set *pRequestedState = BOOTSTRAPPER_REQUEST_STATE_ABSENT. This didn't work and caused the setup to go into an infinite loop launching itself again and again. Does my code look correct? Neil -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 17 September 2012 18:39 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bootstrapper Upgrade Detection You should be able to request ABSENT for the OnPlanRelatedBundle() of the bundle that has the same version. The default is NONE so it stays. On Mon, Sep 17, 2012 at 10:03 AM, Neil Sleightholm n...@x2systems.com wrote: The BootstrapperApplication can override the default logic to do whichever you want. However, the wixstdba does not, so you get the default behavior of the engine. If you have time I'd be interested to know how, I have looked at this and as far as I can tell it is baked in to the Engine and I couldn't find any way to override it. Neil -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 17 September 2012 17:28 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bootstrapper Upgrade Detection The default upgrade logic in the Burn engine does not block and does not upgrade bundles with the same version. That is pretty arguably wrong (and is the bug Neil is referring to). smile/ The BootstrapperApplication can override the default logic to do whichever you want. However, the wixstdba does not, so you get the default behavior of the engine. Most likely, if you continue to rebuild the Bundle but keep the version the same, you have multiple bundles registered on your machine. Go to ProgramsFeatures (aka: ARP) and remove them all. Package reference counting with all those Bundles still installed will likely be very confusing. smile/ -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching http://RobMensching.com LLC -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ WiX-users
Re: [WiX-users] Bootstrapper Upgrade Detection
So only set *pRequestedState = BOOTSTRAPPER_REQUEST_STATE_ABSENT if BOOTSTRAPPER_RELATION_NONE == relationType ? Neil -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 21 September 2012 18:23 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bootstrapper Upgrade Detection Heh, heh, yeah, you'll go into an infinite loop if the two equal bundles keep upgrading each other. I bet you ended up with thousands of burn processes running trying to upgrade each other. Heh. You probably need to throw in the relationType provided from the Command line to make sure you don't start another upgrade when you are doing an upgrade. On Fri, Sep 21, 2012 at 7:23 AM, Gregory Beaty greg.bea...@gmail.comwrote: Any answer to this? Greg Beaty greg.bea...@gmail.com On Tue, Sep 18, 2012 at 1:00 PM, Neil Sleightholm n...@x2systems.com wrote: This is what I tried, in OnDetectRelatedBundle() save the operation. In OnPlanRelatedBundle() if the saved operation == BOOTSTRAPPER_RELATED_OPERATION_NONE (which from previous emails I believe indicates that the version matches) then set *pRequestedState = BOOTSTRAPPER_REQUEST_STATE_ABSENT. This didn't work and caused the setup to go into an infinite loop launching itself again and again. Does my code look correct? Neil -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 17 September 2012 18:39 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bootstrapper Upgrade Detection You should be able to request ABSENT for the OnPlanRelatedBundle() of the bundle that has the same version. The default is NONE so it stays. On Mon, Sep 17, 2012 at 10:03 AM, Neil Sleightholm n...@x2systems.com wrote: The BootstrapperApplication can override the default logic to do whichever you want. However, the wixstdba does not, so you get the default behavior of the engine. If you have time I'd be interested to know how, I have looked at this and as far as I can tell it is baked in to the Engine and I couldn't find any way to override it. Neil -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 17 September 2012 17:28 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bootstrapper Upgrade Detection The default upgrade logic in the Burn engine does not block and does not upgrade bundles with the same version. That is pretty arguably wrong (and is the bug Neil is referring to). smile/ The BootstrapperApplication can override the default logic to do whichever you want. However, the wixstdba does not, so you get the default behavior of the engine. Most likely, if you continue to rebuild the Bundle but keep the version the same, you have multiple bundles registered on your machine. Go to ProgramsFeatures (aka: ARP) and remove them all. Package reference counting with all those Bundles still installed will likely be very confusing. smile/ -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching http://RobMensching.com LLC -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bootstrapper Upgrade Detection
I would say UPGRADE != relationType otherwise you'll be messing with add-on and patch bundles too, I think. On Fri, Sep 21, 2012 at 10:56 AM, Neil Sleightholm n...@x2systems.comwrote: So only set *pRequestedState = BOOTSTRAPPER_REQUEST_STATE_ABSENT if BOOTSTRAPPER_RELATION_NONE == relationType ? Neil -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 21 September 2012 18:23 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bootstrapper Upgrade Detection Heh, heh, yeah, you'll go into an infinite loop if the two equal bundles keep upgrading each other. I bet you ended up with thousands of burn processes running trying to upgrade each other. Heh. You probably need to throw in the relationType provided from the Command line to make sure you don't start another upgrade when you are doing an upgrade. On Fri, Sep 21, 2012 at 7:23 AM, Gregory Beaty greg.bea...@gmail.com wrote: Any answer to this? Greg Beaty greg.bea...@gmail.com On Tue, Sep 18, 2012 at 1:00 PM, Neil Sleightholm n...@x2systems.com wrote: This is what I tried, in OnDetectRelatedBundle() save the operation. In OnPlanRelatedBundle() if the saved operation == BOOTSTRAPPER_RELATED_OPERATION_NONE (which from previous emails I believe indicates that the version matches) then set *pRequestedState = BOOTSTRAPPER_REQUEST_STATE_ABSENT. This didn't work and caused the setup to go into an infinite loop launching itself again and again. Does my code look correct? Neil -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 17 September 2012 18:39 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bootstrapper Upgrade Detection You should be able to request ABSENT for the OnPlanRelatedBundle() of the bundle that has the same version. The default is NONE so it stays. On Mon, Sep 17, 2012 at 10:03 AM, Neil Sleightholm n...@x2systems.com wrote: The BootstrapperApplication can override the default logic to do whichever you want. However, the wixstdba does not, so you get the default behavior of the engine. If you have time I'd be interested to know how, I have looked at this and as far as I can tell it is baked in to the Engine and I couldn't find any way to override it. Neil -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 17 September 2012 17:28 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bootstrapper Upgrade Detection The default upgrade logic in the Burn engine does not block and does not upgrade bundles with the same version. That is pretty arguably wrong (and is the bug Neil is referring to). smile/ The BootstrapperApplication can override the default logic to do whichever you want. However, the wixstdba does not, so you get the default behavior of the engine. Most likely, if you continue to rebuild the Bundle but keep the version the same, you have multiple bundles registered on your machine. Go to ProgramsFeatures (aka: ARP) and remove them all. Package reference counting with all those Bundles still installed will likely be very confusing. smile/ -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching http://RobMensching.com LLC -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint
Re: [WiX-users] Bootstrapper Upgrade Detection
] Bootstrapper Upgrade Detection Even my different version upgrades don't remove the previous installed version. I seem to have problems uninstalling a previous bundle from an upgraded bundle. I believe the logs always indicate there is a dependency which can't be possible since I only have one MSI package in the chain. This kind of leads me to believe that Burn handles repairs differently as well. In my old bootstrapper repairs worked fine, but when using Burn it seems that the StopServices action is never called and instead WixRemoveFoldersEx is called which introduces issues with my application because my service has exclusive locks on some files. Greg Beaty greg.bea...@gmail.com On Sun, Sep 16, 2012 at 12:17 PM, Neil Sleightholm n...@x2systems.com wrote: Burn doesn't support same version upgrades, I have questioned this before as I think it should. I thought I had raised this as a bug/feature request but can't find it now. Neil -Original Message- From: Gregory Beaty [mailto:greg.bea...@gmail.com] Sent: 16 September 2012 15:27 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bootstrapper Upgrade Detection 1. Wix supports same version major upgrades that are the same version using the SameVersion flag. Why isn't Burn using this as well, or is there a way to turn it on? Greg Beaty greg.bea...@gmail.com On Fri, Sep 14, 2012 at 1:01 AM, Rob Mensching r...@robmensching.com wrote: 1. Bundles with the same UpgradeCode have an upgrade relationship.The higher version removes the lower version. Same versions but built at different times can end up in the situation you describe. 2. There should be very few differences between gettinga BA written for NETFX 3.5 vs. 4.0. Actually installing the NETFX 3.5 may be trickier but creating an ExePackage and referencing that via the WixMbaPrereqPackageId is all the same. On Thu, Sep 13, 2012 at 9:18 PM, Gregory Beaty gbe...@spsu.edu wrote: Thanks Rob. I do have another issue. How do I disable the ability for the BA to install multiple versions of my application? It seems that during an upgrade it installs an entirely new app and there ends up being multiple entries in Add/Remove programs. Are there any examples of a managed BA for .Net 3.5? It seems like no matter how I bundle the .Net package, author the bundle, and configure the app.config file I can not get the BA to effectively install the framework then my application. It installs the framework then it opens the the UI shell used for the framework install again and never installs my program. My application is instead replaced by UI shell that the framework installer uses. Does that make sense, and if so is that a bug? *Thanks, Greg Beaty * *LinkedIn http://www.linkedin.com/pub/gregory-beaty-jr/42/b6a/a96 | Personal http://goog_419374978**Website http://www.gregbeaty.net/ | ** gbe...@spsu.edu* On Thu, Sep 13, 2012 at 10:21 PM, Rob Mensching r...@robmensching.com wrote: The RelatedOption.None is how you know. In WiX v3.7 you also get the relation type which will further inform you that you have a related Bundle that is an upgrade but it's operation is None (i.e not upgrade and not downgrade). On Thu, Sep 13, 2012 at 4:54 AM, Gregory Beaty greg.bea...@gmail.com wrote: Hello, My WiX MSI package allows same version upgrades with: MajorUpgrade Schedule=afterInstallInitialize AllowSameVersionUpgrades=yes DowngradeErrorMessage=A newer version of [ProductName] is already installed. /. However when using this with my Manager Bootstrapper Application I never get the RelatedOperation of a MinorUpgrade or MajorUpgrade in the DetectRelatedBundle event. I only get RelatedOption.None. The process
Re: [WiX-users] Bootstrapper Upgrade Detection
, the wixstdba does not, so you get the default behavior of the engine. Most likely, if you continue to rebuild the Bundle but keep the version the same, you have multiple bundles registered on your machine. Go to ProgramsFeatures (aka: ARP) and remove them all. Package reference counting with all those Bundles still installed will likely be very confusing. smile/ On Mon, Sep 17, 2012 at 4:38 AM, Gregory Beaty greg.bea...@gmail.com wrote: I'm pretty sure its the package but I could be wrong. On Sep 17, 2012 4:33 AM, Neil Sleightholm n...@x2systems.com wrote: Do you mean multiple entries from your burn package or the msi? Neil Does this mean I should remove the AllowSameVersions from the MajorUpgrade tag also? Right now I still get multiple entries with different versions but I still have the flag there. Greg Beaty greg.bea...@gmail.com On Sun, Sep 16, 2012 at 12:41 PM, Neil Sleightholm n...@x2systems.comwrote: I had this issue when I had done some same version installs and then started changing the version; the cause was multiple entries in ARP. It might we worth checking this, I found if I removed all the versions then the upgrades started working. Neil -Original Message- From: Gregory Beaty [mailto:greg.bea...@gmail.com] Sent: 16 September 2012 17:36 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bootstrapper Upgrade Detection Even my different version upgrades don't remove the previous installed version. I seem to have problems uninstalling a previous bundle from an upgraded bundle. I believe the logs always indicate there is a dependency which can't be possible since I only have one MSI package in the chain. This kind of leads me to believe that Burn handles repairs differently as well. In my old bootstrapper repairs worked fine, but when using Burn it seems that the StopServices action is never called and instead WixRemoveFoldersEx is called which introduces issues with my application because my service has exclusive locks on some files. Greg Beaty greg.bea...@gmail.com On Sun, Sep 16, 2012 at 12:17 PM, Neil Sleightholm n...@x2systems.com wrote: Burn doesn't support same version upgrades, I have questioned this before as I think it should. I thought I had raised this as a bug/feature request but can't find it now. Neil -Original Message- From: Gregory Beaty [mailto:greg.bea...@gmail.com] Sent: 16 September 2012 15:27 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bootstrapper Upgrade Detection 1. Wix supports same version major upgrades that are the same version using the SameVersion flag. Why isn't Burn using this as well, or is there a way to turn it on? Greg Beaty greg.bea...@gmail.com On Fri, Sep 14, 2012 at 1:01 AM, Rob Mensching r...@robmensching.com wrote: 1. Bundles with the same UpgradeCode have an upgrade relationship.The higher version removes the lower version. Same versions but built at different times can end up in the situation you describe. 2. There should be very few differences between gettinga BA written for NETFX 3.5 vs. 4.0. Actually installing the NETFX 3.5 may be trickier but creating an ExePackage and referencing that via the WixMbaPrereqPackageId is all the same. On Thu, Sep 13, 2012 at 9:18 PM, Gregory Beaty gbe...@spsu.edu wrote: Thanks Rob. I do have another issue. How do I disable the ability for the BA to install multiple versions of my application? It seems that during an upgrade it installs an entirely new app and there ends up being multiple entries in Add/Remove programs. Are there any examples of a managed BA for .Net 3.5? It seems like no matter how I bundle the .Net package, author the bundle, and configure the app.config file I can not get the BA to effectively install
Re: [WiX-users] Bootstrapper Upgrade Detection
This is what I tried, in OnDetectRelatedBundle() save the operation. In OnPlanRelatedBundle() if the saved operation == BOOTSTRAPPER_RELATED_OPERATION_NONE (which from previous emails I believe indicates that the version matches) then set *pRequestedState = BOOTSTRAPPER_REQUEST_STATE_ABSENT. This didn't work and caused the setup to go into an infinite loop launching itself again and again. Does my code look correct? Neil -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 17 September 2012 18:39 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bootstrapper Upgrade Detection You should be able to request ABSENT for the OnPlanRelatedBundle() of the bundle that has the same version. The default is NONE so it stays. On Mon, Sep 17, 2012 at 10:03 AM, Neil Sleightholm n...@x2systems.comwrote: The BootstrapperApplication can override the default logic to do whichever you want. However, the wixstdba does not, so you get the default behavior of the engine. If you have time I'd be interested to know how, I have looked at this and as far as I can tell it is baked in to the Engine and I couldn't find any way to override it. Neil -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 17 September 2012 17:28 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bootstrapper Upgrade Detection The default upgrade logic in the Burn engine does not block and does not upgrade bundles with the same version. That is pretty arguably wrong (and is the bug Neil is referring to). smile/ The BootstrapperApplication can override the default logic to do whichever you want. However, the wixstdba does not, so you get the default behavior of the engine. Most likely, if you continue to rebuild the Bundle but keep the version the same, you have multiple bundles registered on your machine. Go to ProgramsFeatures (aka: ARP) and remove them all. Package reference counting with all those Bundles still installed will likely be very confusing. smile/ -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching http://RobMensching.com LLC -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bootstrapper Upgrade Detection
Do you mean multiple entries from your burn package or the msi? Neil Does this mean I should remove the AllowSameVersions from the MajorUpgrade tag also? Right now I still get multiple entries with different versions but I still have the flag there. Greg Beaty greg.bea...@gmail.com On Sun, Sep 16, 2012 at 12:41 PM, Neil Sleightholm n...@x2systems.comwrote: I had this issue when I had done some same version installs and then started changing the version; the cause was multiple entries in ARP. It might we worth checking this, I found if I removed all the versions then the upgrades started working. Neil -Original Message- From: Gregory Beaty [mailto:greg.bea...@gmail.com] Sent: 16 September 2012 17:36 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bootstrapper Upgrade Detection Even my different version upgrades don't remove the previous installed version. I seem to have problems uninstalling a previous bundle from an upgraded bundle. I believe the logs always indicate there is a dependency which can't be possible since I only have one MSI package in the chain. This kind of leads me to believe that Burn handles repairs differently as well. In my old bootstrapper repairs worked fine, but when using Burn it seems that the StopServices action is never called and instead WixRemoveFoldersEx is called which introduces issues with my application because my service has exclusive locks on some files. Greg Beaty greg.bea...@gmail.com On Sun, Sep 16, 2012 at 12:17 PM, Neil Sleightholm n...@x2systems.com wrote: Burn doesn't support same version upgrades, I have questioned this before as I think it should. I thought I had raised this as a bug/feature request but can't find it now. Neil -Original Message- From: Gregory Beaty [mailto:greg.bea...@gmail.com] Sent: 16 September 2012 15:27 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bootstrapper Upgrade Detection 1. Wix supports same version major upgrades that are the same version using the SameVersion flag. Why isn't Burn using this as well, or is there a way to turn it on? Greg Beaty greg.bea...@gmail.com On Fri, Sep 14, 2012 at 1:01 AM, Rob Mensching r...@robmensching.com wrote: 1. Bundles with the same UpgradeCode have an upgrade relationship.The higher version removes the lower version. Same versions but built at different times can end up in the situation you describe. 2. There should be very few differences between gettinga BA written for NETFX 3.5 vs. 4.0. Actually installing the NETFX 3.5 may be trickier but creating an ExePackage and referencing that via the WixMbaPrereqPackageId is all the same. On Thu, Sep 13, 2012 at 9:18 PM, Gregory Beaty gbe...@spsu.edu wrote: Thanks Rob. I do have another issue. How do I disable the ability for the BA to install multiple versions of my application? It seems that during an upgrade it installs an entirely new app and there ends up being multiple entries in Add/Remove programs. Are there any examples of a managed BA for .Net 3.5? It seems like no matter how I bundle the .Net package, author the bundle, and configure the app.config file I can not get the BA to effectively install the framework then my application. It installs the framework then it opens the the UI shell used for the framework install again and never installs my program. My application is instead replaced by UI shell that the framework installer uses. Does that make sense, and if so is that a bug? *Thanks, Greg Beaty * *LinkedIn http://www.linkedin.com/pub/gregory-beaty-jr/42/b6a/a96 | Personal http://goog_419374978**Website http://www.gregbeaty.net/ | ** gbe...@spsu.edu* On Thu, Sep 13, 2012 at 10:21 PM, Rob Mensching r...@robmensching.com wrote: The RelatedOption.None is how you know. In WiX v3.7 you also get the relation type which will further inform you that you have a related Bundle that is an upgrade but it's operation is None (i.e not upgrade and not downgrade). On Thu, Sep 13, 2012 at 4:54 AM, Gregory Beaty greg.bea...@gmail.com wrote: Hello, My WiX MSI package allows same version upgrades with: MajorUpgrade Schedule=afterInstallInitialize AllowSameVersionUpgrades=yes DowngradeErrorMessage=A newer version of [ProductName] is already installed. /. However when using this with my Manager Bootstrapper Application I never get the RelatedOperation of a MinorUpgrade or MajorUpgrade in the DetectRelatedBundle event. I only get RelatedOption.None. The process indeed upgrades the previous installation but this hinders my ability to inform the user inside
Re: [WiX-users] Bootstrapper Upgrade Detection
I'm pretty sure its the package but I could be wrong. On Sep 17, 2012 4:33 AM, Neil Sleightholm n...@x2systems.com wrote: Do you mean multiple entries from your burn package or the msi? Neil Does this mean I should remove the AllowSameVersions from the MajorUpgrade tag also? Right now I still get multiple entries with different versions but I still have the flag there. Greg Beaty greg.bea...@gmail.com On Sun, Sep 16, 2012 at 12:41 PM, Neil Sleightholm n...@x2systems.comwrote: I had this issue when I had done some same version installs and then started changing the version; the cause was multiple entries in ARP. It might we worth checking this, I found if I removed all the versions then the upgrades started working. Neil -Original Message- From: Gregory Beaty [mailto:greg.bea...@gmail.com] Sent: 16 September 2012 17:36 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bootstrapper Upgrade Detection Even my different version upgrades don't remove the previous installed version. I seem to have problems uninstalling a previous bundle from an upgraded bundle. I believe the logs always indicate there is a dependency which can't be possible since I only have one MSI package in the chain. This kind of leads me to believe that Burn handles repairs differently as well. In my old bootstrapper repairs worked fine, but when using Burn it seems that the StopServices action is never called and instead WixRemoveFoldersEx is called which introduces issues with my application because my service has exclusive locks on some files. Greg Beaty greg.bea...@gmail.com On Sun, Sep 16, 2012 at 12:17 PM, Neil Sleightholm n...@x2systems.com wrote: Burn doesn't support same version upgrades, I have questioned this before as I think it should. I thought I had raised this as a bug/feature request but can't find it now. Neil -Original Message- From: Gregory Beaty [mailto:greg.bea...@gmail.com] Sent: 16 September 2012 15:27 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bootstrapper Upgrade Detection 1. Wix supports same version major upgrades that are the same version using the SameVersion flag. Why isn't Burn using this as well, or is there a way to turn it on? Greg Beaty greg.bea...@gmail.com On Fri, Sep 14, 2012 at 1:01 AM, Rob Mensching r...@robmensching.com wrote: 1. Bundles with the same UpgradeCode have an upgrade relationship.The higher version removes the lower version. Same versions but built at different times can end up in the situation you describe. 2. There should be very few differences between gettinga BA written for NETFX 3.5 vs. 4.0. Actually installing the NETFX 3.5 may be trickier but creating an ExePackage and referencing that via the WixMbaPrereqPackageId is all the same. On Thu, Sep 13, 2012 at 9:18 PM, Gregory Beaty gbe...@spsu.edu wrote: Thanks Rob. I do have another issue. How do I disable the ability for the BA to install multiple versions of my application? It seems that during an upgrade it installs an entirely new app and there ends up being multiple entries in Add/Remove programs. Are there any examples of a managed BA for .Net 3.5? It seems like no matter how I bundle the .Net package, author the bundle, and configure the app.config file I can not get the BA to effectively install the framework then my application. It installs the framework then it opens the the UI shell used for the framework install again and never installs my program. My application is instead replaced by UI shell that the framework installer uses. Does that make sense, and if so is that a bug? *Thanks, Greg Beaty * *LinkedIn http://www.linkedin.com/pub/gregory-beaty-jr/42/b6a/a96 | Personal http://goog_419374978**Website http://www.gregbeaty.net/ | ** gbe...@spsu.edu* On Thu, Sep 13, 2012 at 10:21 PM, Rob Mensching r...@robmensching.com wrote: The RelatedOption.None is how you know. In WiX v3.7 you also get the relation type which will further inform you that you have a related Bundle that is an upgrade but it's operation is None (i.e not upgrade and not downgrade). On Thu, Sep 13, 2012 at 4:54 AM, Gregory Beaty greg.bea...@gmail.com wrote: Hello, My WiX MSI package allows same version upgrades with: MajorUpgrade Schedule=afterInstallInitialize AllowSameVersionUpgrades=yes DowngradeErrorMessage=A newer version of [ProductName] is already installed. /. However when using this with my Manager Bootstrapper Application I never
Re: [WiX-users] Bootstrapper Upgrade Detection
The default upgrade logic in the Burn engine does not block and does not upgrade bundles with the same version. That is pretty arguably wrong (and is the bug Neil is referring to). smile/ The BootstrapperApplication can override the default logic to do whichever you want. However, the wixstdba does not, so you get the default behavior of the engine. Most likely, if you continue to rebuild the Bundle but keep the version the same, you have multiple bundles registered on your machine. Go to ProgramsFeatures (aka: ARP) and remove them all. Package reference counting with all those Bundles still installed will likely be very confusing. smile/ On Mon, Sep 17, 2012 at 4:38 AM, Gregory Beaty greg.bea...@gmail.comwrote: I'm pretty sure its the package but I could be wrong. On Sep 17, 2012 4:33 AM, Neil Sleightholm n...@x2systems.com wrote: Do you mean multiple entries from your burn package or the msi? Neil Does this mean I should remove the AllowSameVersions from the MajorUpgrade tag also? Right now I still get multiple entries with different versions but I still have the flag there. Greg Beaty greg.bea...@gmail.com On Sun, Sep 16, 2012 at 12:41 PM, Neil Sleightholm n...@x2systems.comwrote: I had this issue when I had done some same version installs and then started changing the version; the cause was multiple entries in ARP. It might we worth checking this, I found if I removed all the versions then the upgrades started working. Neil -Original Message- From: Gregory Beaty [mailto:greg.bea...@gmail.com] Sent: 16 September 2012 17:36 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bootstrapper Upgrade Detection Even my different version upgrades don't remove the previous installed version. I seem to have problems uninstalling a previous bundle from an upgraded bundle. I believe the logs always indicate there is a dependency which can't be possible since I only have one MSI package in the chain. This kind of leads me to believe that Burn handles repairs differently as well. In my old bootstrapper repairs worked fine, but when using Burn it seems that the StopServices action is never called and instead WixRemoveFoldersEx is called which introduces issues with my application because my service has exclusive locks on some files. Greg Beaty greg.bea...@gmail.com On Sun, Sep 16, 2012 at 12:17 PM, Neil Sleightholm n...@x2systems.com wrote: Burn doesn't support same version upgrades, I have questioned this before as I think it should. I thought I had raised this as a bug/feature request but can't find it now. Neil -Original Message- From: Gregory Beaty [mailto:greg.bea...@gmail.com] Sent: 16 September 2012 15:27 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bootstrapper Upgrade Detection 1. Wix supports same version major upgrades that are the same version using the SameVersion flag. Why isn't Burn using this as well, or is there a way to turn it on? Greg Beaty greg.bea...@gmail.com On Fri, Sep 14, 2012 at 1:01 AM, Rob Mensching r...@robmensching.com wrote: 1. Bundles with the same UpgradeCode have an upgrade relationship.The higher version removes the lower version. Same versions but built at different times can end up in the situation you describe. 2. There should be very few differences between gettinga BA written for NETFX 3.5 vs. 4.0. Actually installing the NETFX 3.5 may be trickier but creating an ExePackage and referencing that via the WixMbaPrereqPackageId is all the same. On Thu, Sep 13, 2012 at 9:18 PM, Gregory Beaty gbe...@spsu.edu wrote: Thanks Rob. I do have another issue. How do I disable the ability for the BA to install multiple versions of my application? It seems that during an upgrade it installs an entirely new app and there ends up being multiple entries in Add/Remove programs. Are there any examples of a managed BA for .Net 3.5? It seems like no matter how I bundle the .Net package, author the bundle, and configure the app.config file I can not get the BA to effectively install the framework then my application. It installs the framework then it opens the the UI shell used for the framework install again and never installs my program. My application is instead replaced by UI shell that the framework installer uses. Does that make sense, and if so is that a bug? *Thanks, Greg Beaty * *LinkedIn http://www.linkedin.com/pub/gregory-beaty-jr/42/b6a/a96 | Personal http://goog_419374978**Website http://www.gregbeaty.net/ | ** gbe
Re: [WiX-users] Bootstrapper Upgrade Detection
The BootstrapperApplication can override the default logic to do whichever you want. However, the wixstdba does not, so you get the default behavior of the engine. If you have time I'd be interested to know how, I have looked at this and as far as I can tell it is baked in to the Engine and I couldn't find any way to override it. Neil -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 17 September 2012 17:28 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bootstrapper Upgrade Detection The default upgrade logic in the Burn engine does not block and does not upgrade bundles with the same version. That is pretty arguably wrong (and is the bug Neil is referring to). smile/ The BootstrapperApplication can override the default logic to do whichever you want. However, the wixstdba does not, so you get the default behavior of the engine. Most likely, if you continue to rebuild the Bundle but keep the version the same, you have multiple bundles registered on your machine. Go to ProgramsFeatures (aka: ARP) and remove them all. Package reference counting with all those Bundles still installed will likely be very confusing. smile/ -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bootstrapper Upgrade Detection
Sorry for all the posts but I will explain my problem in more detail. I am not using the wixstdba, I have created my very own managed Bootstrapper Application based loosely on the Wix 3.6 Installer. Everytime I build my solution I increment the version, it is never the same (just for testing purposes). Originally this was not the case and I was essentially doing same version upgrades which resulted in multiple ARP entries. Now, when I install a version, then I try to upgrade to a new version I still always get multiple entries in ARP even though the versions are clearly different (from looking at the version number referenced in ARP). Is there something I am missing? Greg Beaty greg.bea...@gmail.com On Mon, Sep 17, 2012 at 12:27 PM, Rob Mensching r...@robmensching.comwrote: The default upgrade logic in the Burn engine does not block and does not upgrade bundles with the same version. That is pretty arguably wrong (and is the bug Neil is referring to). smile/ The BootstrapperApplication can override the default logic to do whichever you want. However, the wixstdba does not, so you get the default behavior of the engine. Most likely, if you continue to rebuild the Bundle but keep the version the same, you have multiple bundles registered on your machine. Go to ProgramsFeatures (aka: ARP) and remove them all. Package reference counting with all those Bundles still installed will likely be very confusing. smile/ On Mon, Sep 17, 2012 at 4:38 AM, Gregory Beaty greg.bea...@gmail.com wrote: I'm pretty sure its the package but I could be wrong. On Sep 17, 2012 4:33 AM, Neil Sleightholm n...@x2systems.com wrote: Do you mean multiple entries from your burn package or the msi? Neil Does this mean I should remove the AllowSameVersions from the MajorUpgrade tag also? Right now I still get multiple entries with different versions but I still have the flag there. Greg Beaty greg.bea...@gmail.com On Sun, Sep 16, 2012 at 12:41 PM, Neil Sleightholm n...@x2systems.comwrote: I had this issue when I had done some same version installs and then started changing the version; the cause was multiple entries in ARP. It might we worth checking this, I found if I removed all the versions then the upgrades started working. Neil -Original Message- From: Gregory Beaty [mailto:greg.bea...@gmail.com] Sent: 16 September 2012 17:36 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bootstrapper Upgrade Detection Even my different version upgrades don't remove the previous installed version. I seem to have problems uninstalling a previous bundle from an upgraded bundle. I believe the logs always indicate there is a dependency which can't be possible since I only have one MSI package in the chain. This kind of leads me to believe that Burn handles repairs differently as well. In my old bootstrapper repairs worked fine, but when using Burn it seems that the StopServices action is never called and instead WixRemoveFoldersEx is called which introduces issues with my application because my service has exclusive locks on some files. Greg Beaty greg.bea...@gmail.com On Sun, Sep 16, 2012 at 12:17 PM, Neil Sleightholm n...@x2systems.com wrote: Burn doesn't support same version upgrades, I have questioned this before as I think it should. I thought I had raised this as a bug/feature request but can't find it now. Neil -Original Message- From: Gregory Beaty [mailto:greg.bea...@gmail.com] Sent: 16 September 2012 15:27 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bootstrapper Upgrade Detection 1. Wix supports same version major upgrades that are the same version using the SameVersion flag. Why isn't Burn using this as well, or is there a way to turn it on? Greg Beaty greg.bea...@gmail.com On Fri, Sep 14, 2012 at 1:01 AM, Rob Mensching r...@robmensching.com wrote: 1. Bundles with the same UpgradeCode have an upgrade relationship.The higher version removes the lower version. Same versions but built at different times can end up in the situation you describe. 2. There should be very few differences between gettinga BA written for NETFX 3.5 vs. 4.0. Actually installing the NETFX 3.5 may be trickier but creating an ExePackage and referencing that via the WixMbaPrereqPackageId is all the same. On Thu, Sep 13, 2012 at 9:18 PM, Gregory Beaty gbe...@spsu.edu wrote: Thanks Rob. I do have another issue. How do I disable the ability for the BA to install multiple versions of my application? It seems
Re: [WiX-users] Bootstrapper Upgrade Detection
If your UpgradeCodes are correct then I would guess the Bundle upgrade is failing. You should see the new Bundle kick off an uninstall of the old Bundle at the end of the new Bundle's install. If you take a walk through the log files you should be able to see all the calls. On Mon, Sep 17, 2012 at 10:06 AM, Gregory Beaty greg.bea...@gmail.comwrote: Sorry for all the posts but I will explain my problem in more detail. I am not using the wixstdba, I have created my very own managed Bootstrapper Application based loosely on the Wix 3.6 Installer. Everytime I build my solution I increment the version, it is never the same (just for testing purposes). Originally this was not the case and I was essentially doing same version upgrades which resulted in multiple ARP entries. Now, when I install a version, then I try to upgrade to a new version I still always get multiple entries in ARP even though the versions are clearly different (from looking at the version number referenced in ARP). Is there something I am missing? Greg Beaty greg.bea...@gmail.com On Mon, Sep 17, 2012 at 12:27 PM, Rob Mensching r...@robmensching.com wrote: The default upgrade logic in the Burn engine does not block and does not upgrade bundles with the same version. That is pretty arguably wrong (and is the bug Neil is referring to). smile/ The BootstrapperApplication can override the default logic to do whichever you want. However, the wixstdba does not, so you get the default behavior of the engine. Most likely, if you continue to rebuild the Bundle but keep the version the same, you have multiple bundles registered on your machine. Go to ProgramsFeatures (aka: ARP) and remove them all. Package reference counting with all those Bundles still installed will likely be very confusing. smile/ On Mon, Sep 17, 2012 at 4:38 AM, Gregory Beaty greg.bea...@gmail.com wrote: I'm pretty sure its the package but I could be wrong. On Sep 17, 2012 4:33 AM, Neil Sleightholm n...@x2systems.com wrote: Do you mean multiple entries from your burn package or the msi? Neil Does this mean I should remove the AllowSameVersions from the MajorUpgrade tag also? Right now I still get multiple entries with different versions but I still have the flag there. Greg Beaty greg.bea...@gmail.com On Sun, Sep 16, 2012 at 12:41 PM, Neil Sleightholm n...@x2systems.comwrote: I had this issue when I had done some same version installs and then started changing the version; the cause was multiple entries in ARP. It might we worth checking this, I found if I removed all the versions then the upgrades started working. Neil -Original Message- From: Gregory Beaty [mailto:greg.bea...@gmail.com] Sent: 16 September 2012 17:36 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bootstrapper Upgrade Detection Even my different version upgrades don't remove the previous installed version. I seem to have problems uninstalling a previous bundle from an upgraded bundle. I believe the logs always indicate there is a dependency which can't be possible since I only have one MSI package in the chain. This kind of leads me to believe that Burn handles repairs differently as well. In my old bootstrapper repairs worked fine, but when using Burn it seems that the StopServices action is never called and instead WixRemoveFoldersEx is called which introduces issues with my application because my service has exclusive locks on some files. Greg Beaty greg.bea...@gmail.com On Sun, Sep 16, 2012 at 12:17 PM, Neil Sleightholm n...@x2systems.com wrote: Burn doesn't support same version upgrades, I have questioned this before as I think it should. I thought I had raised this as a bug/feature request but can't find it now. Neil -Original Message- From: Gregory Beaty [mailto:greg.bea...@gmail.com] Sent: 16 September 2012 15:27 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bootstrapper Upgrade Detection 1. Wix supports same version major upgrades that are the same version using the SameVersion flag. Why isn't Burn using this as well, or is there a way to turn it on? Greg Beaty greg.bea...@gmail.com On Fri, Sep 14, 2012 at 1:01 AM, Rob Mensching r...@robmensching.com wrote: 1. Bundles with the same UpgradeCode have an upgrade relationship.The higher version removes the lower version. Same versions but built at different times can end up in the situation you describe. 2. There should be very few differences
Re: [WiX-users] Bootstrapper Upgrade Detection
You should be able to request ABSENT for the OnPlanRelatedBundle() of the bundle that has the same version. The default is NONE so it stays. On Mon, Sep 17, 2012 at 10:03 AM, Neil Sleightholm n...@x2systems.comwrote: The BootstrapperApplication can override the default logic to do whichever you want. However, the wixstdba does not, so you get the default behavior of the engine. If you have time I'd be interested to know how, I have looked at this and as far as I can tell it is baked in to the Engine and I couldn't find any way to override it. Neil -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 17 September 2012 17:28 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bootstrapper Upgrade Detection The default upgrade logic in the Burn engine does not block and does not upgrade bundles with the same version. That is pretty arguably wrong (and is the bug Neil is referring to). smile/ The BootstrapperApplication can override the default logic to do whichever you want. However, the wixstdba does not, so you get the default behavior of the engine. Most likely, if you continue to rebuild the Bundle but keep the version the same, you have multiple bundles registered on your machine. Go to ProgramsFeatures (aka: ARP) and remove them all. Package reference counting with all those Bundles still installed will likely be very confusing. smile/ -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching http://RobMensching.com LLC -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bootstrapper Upgrade Detection
I don't have access to the logs right now but Rob I think you are right. I remember when I provided an uninstall button inside of the upgraded bundle it usually failed because of some dependency issue of the package (from the logs), which I don't quite understand since there is only one package in the bundle. I will look more into that. Thanks for the guidance and the info on overriding the behavior. Greg Beaty greg.bea...@gmail.com On Mon, Sep 17, 2012 at 1:37 PM, Rob Mensching r...@robmensching.com wrote: If your UpgradeCodes are correct then I would guess the Bundle upgrade is failing. You should see the new Bundle kick off an uninstall of the old Bundle at the end of the new Bundle's install. If you take a walk through the log files you should be able to see all the calls. On Mon, Sep 17, 2012 at 10:06 AM, Gregory Beaty greg.bea...@gmail.com wrote: Sorry for all the posts but I will explain my problem in more detail. I am not using the wixstdba, I have created my very own managed Bootstrapper Application based loosely on the Wix 3.6 Installer. Everytime I build my solution I increment the version, it is never the same (just for testing purposes). Originally this was not the case and I was essentially doing same version upgrades which resulted in multiple ARP entries. Now, when I install a version, then I try to upgrade to a new version I still always get multiple entries in ARP even though the versions are clearly different (from looking at the version number referenced in ARP). Is there something I am missing? Greg Beaty greg.bea...@gmail.com On Mon, Sep 17, 2012 at 12:27 PM, Rob Mensching r...@robmensching.com wrote: The default upgrade logic in the Burn engine does not block and does not upgrade bundles with the same version. That is pretty arguably wrong (and is the bug Neil is referring to). smile/ The BootstrapperApplication can override the default logic to do whichever you want. However, the wixstdba does not, so you get the default behavior of the engine. Most likely, if you continue to rebuild the Bundle but keep the version the same, you have multiple bundles registered on your machine. Go to ProgramsFeatures (aka: ARP) and remove them all. Package reference counting with all those Bundles still installed will likely be very confusing. smile/ On Mon, Sep 17, 2012 at 4:38 AM, Gregory Beaty greg.bea...@gmail.com wrote: I'm pretty sure its the package but I could be wrong. On Sep 17, 2012 4:33 AM, Neil Sleightholm n...@x2systems.com wrote: Do you mean multiple entries from your burn package or the msi? Neil Does this mean I should remove the AllowSameVersions from the MajorUpgrade tag also? Right now I still get multiple entries with different versions but I still have the flag there. Greg Beaty greg.bea...@gmail.com On Sun, Sep 16, 2012 at 12:41 PM, Neil Sleightholm n...@x2systems.comwrote: I had this issue when I had done some same version installs and then started changing the version; the cause was multiple entries in ARP. It might we worth checking this, I found if I removed all the versions then the upgrades started working. Neil -Original Message- From: Gregory Beaty [mailto:greg.bea...@gmail.com] Sent: 16 September 2012 17:36 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bootstrapper Upgrade Detection Even my different version upgrades don't remove the previous installed version. I seem to have problems uninstalling a previous bundle from an upgraded bundle. I believe the logs always indicate there is a dependency which can't be possible since I only have one MSI package in the chain. This kind of leads me to believe that Burn handles repairs differently as well. In my old bootstrapper repairs worked fine, but when using Burn it seems that the StopServices action is never called and instead WixRemoveFoldersEx is called which introduces issues with my application because my service has exclusive locks on some files. Greg Beaty greg.bea...@gmail.com On Sun, Sep 16, 2012 at 12:17 PM, Neil Sleightholm n...@x2systems.com wrote: Burn doesn't support same version upgrades, I have questioned this before as I think it should. I thought I had raised this as a bug/feature request but can't find it now. Neil -Original Message- From: Gregory Beaty [mailto:greg.bea...@gmail.com] Sent: 16 September 2012 15:27 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bootstrapper Upgrade Detection
Re: [WiX-users] Bootstrapper Upgrade Detection
So after doing a ton of analysis I figured out my problem. Here is the process in which my upgraded bundle goes through: Detect packages, apply begin, uninstall existing msi package, install new msi package, apply complete, detect packages, apply begin, uninstall previous bundle. It gets to the point where it attempts to uninstall the previous bundle, but never completes, which I believe is occurring because of the Invokes and the manipulation of the window pointer a second time around. I used the Wix installer as my baseline and it looks like it wasn't made for running an additional detect packages after the initial bundle finishes applying (I could be wrong). When I switch to using the wixstdba the process works perfectly and I never get multiple ARP entries (the sequence is the same as the mba). Is there anyway that I can accomplish this with the managed bootstrapper? (Is there any source code for the wixstddba?) Greg Beaty greg.bea...@gmail.com On Mon, Sep 17, 2012 at 1:54 PM, Gregory Beaty greg.bea...@gmail.comwrote: I don't have access to the logs right now but Rob I think you are right. I remember when I provided an uninstall button inside of the upgraded bundle it usually failed because of some dependency issue of the package (from the logs), which I don't quite understand since there is only one package in the bundle. I will look more into that. Thanks for the guidance and the info on overriding the behavior. Greg Beaty greg.bea...@gmail.com On Mon, Sep 17, 2012 at 1:37 PM, Rob Mensching r...@robmensching.comwrote: If your UpgradeCodes are correct then I would guess the Bundle upgrade is failing. You should see the new Bundle kick off an uninstall of the old Bundle at the end of the new Bundle's install. If you take a walk through the log files you should be able to see all the calls. On Mon, Sep 17, 2012 at 10:06 AM, Gregory Beaty greg.bea...@gmail.com wrote: Sorry for all the posts but I will explain my problem in more detail. I am not using the wixstdba, I have created my very own managed Bootstrapper Application based loosely on the Wix 3.6 Installer. Everytime I build my solution I increment the version, it is never the same (just for testing purposes). Originally this was not the case and I was essentially doing same version upgrades which resulted in multiple ARP entries. Now, when I install a version, then I try to upgrade to a new version I still always get multiple entries in ARP even though the versions are clearly different (from looking at the version number referenced in ARP). Is there something I am missing? Greg Beaty greg.bea...@gmail.com On Mon, Sep 17, 2012 at 12:27 PM, Rob Mensching r...@robmensching.com wrote: The default upgrade logic in the Burn engine does not block and does not upgrade bundles with the same version. That is pretty arguably wrong (and is the bug Neil is referring to). smile/ The BootstrapperApplication can override the default logic to do whichever you want. However, the wixstdba does not, so you get the default behavior of the engine. Most likely, if you continue to rebuild the Bundle but keep the version the same, you have multiple bundles registered on your machine. Go to ProgramsFeatures (aka: ARP) and remove them all. Package reference counting with all those Bundles still installed will likely be very confusing. smile/ On Mon, Sep 17, 2012 at 4:38 AM, Gregory Beaty greg.bea...@gmail.com wrote: I'm pretty sure its the package but I could be wrong. On Sep 17, 2012 4:33 AM, Neil Sleightholm n...@x2systems.com wrote: Do you mean multiple entries from your burn package or the msi? Neil Does this mean I should remove the AllowSameVersions from the MajorUpgrade tag also? Right now I still get multiple entries with different versions but I still have the flag there. Greg Beaty greg.bea...@gmail.com On Sun, Sep 16, 2012 at 12:41 PM, Neil Sleightholm n...@x2systems.comwrote: I had this issue when I had done some same version installs and then started changing the version; the cause was multiple entries in ARP. It might we worth checking this, I found if I removed all the versions then the upgrades started working. Neil -Original Message- From: Gregory Beaty [mailto:greg.bea...@gmail.com] Sent: 16 September 2012 17:36 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bootstrapper Upgrade Detection Even my different version upgrades don't remove the previous installed version. I seem to have problems uninstalling a previous bundle from an upgraded bundle. I believe the logs always indicate there is a dependency which can't be possible since I only have one MSI
Re: [WiX-users] Bootstrapper Upgrade Detection
1. Wix supports same version major upgrades that are the same version using the SameVersion flag. Why isn't Burn using this as well, or is there a way to turn it on? Greg Beaty greg.bea...@gmail.com On Fri, Sep 14, 2012 at 1:01 AM, Rob Mensching r...@robmensching.com wrote: 1. Bundles with the same UpgradeCode have an upgrade relationship.The higher version removes the lower version. Same versions but built at different times can end up in the situation you describe. 2. There should be very few differences between gettinga BA written for NETFX 3.5 vs. 4.0. Actually installing the NETFX 3.5 may be trickier but creating an ExePackage and referencing that via the WixMbaPrereqPackageId is all the same. On Thu, Sep 13, 2012 at 9:18 PM, Gregory Beaty gbe...@spsu.edu wrote: Thanks Rob. I do have another issue. How do I disable the ability for the BA to install multiple versions of my application? It seems that during an upgrade it installs an entirely new app and there ends up being multiple entries in Add/Remove programs. Are there any examples of a managed BA for .Net 3.5? It seems like no matter how I bundle the .Net package, author the bundle, and configure the app.config file I can not get the BA to effectively install the framework then my application. It installs the framework then it opens the the UI shell used for the framework install again and never installs my program. My application is instead replaced by UI shell that the framework installer uses. Does that make sense, and if so is that a bug? *Thanks, Greg Beaty * *LinkedIn http://www.linkedin.com/pub/gregory-beaty-jr/42/b6a/a96 | Personal http://goog_419374978**Website http://www.gregbeaty.net/ | ** gbe...@spsu.edu* On Thu, Sep 13, 2012 at 10:21 PM, Rob Mensching r...@robmensching.com wrote: The RelatedOption.None is how you know. In WiX v3.7 you also get the relation type which will further inform you that you have a related Bundle that is an upgrade but it's operation is None (i.e not upgrade and not downgrade). On Thu, Sep 13, 2012 at 4:54 AM, Gregory Beaty greg.bea...@gmail.com wrote: Hello, My WiX MSI package allows same version upgrades with: MajorUpgrade Schedule=afterInstallInitialize AllowSameVersionUpgrades=yes DowngradeErrorMessage=A newer version of [ProductName] is already installed. /. However when using this with my Manager Bootstrapper Application I never get the RelatedOperation of a MinorUpgrade or MajorUpgrade in the DetectRelatedBundle event. I only get RelatedOption.None. The process indeed upgrades the previous installation but this hinders my ability to inform the user inside of the Bootstrapper Application that the install is an upgrade. Is this a bug or is there something I am doing wrong? Is the problem that the package actions aren't scheduled until it is actually executing? Greg Beaty g gbe...@spsu.edureg.bea...@gmail.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching http://RobMensching.com LLC -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching http://RobMensching.com LLC -- Got visibility? Most devs has no idea what their production app looks like.
Re: [WiX-users] Bootstrapper Upgrade Detection
Also I just re-ran the upgrade and the versions are different, but it still places two different versions into the Add/Remove programs list. Greg Beaty greg.bea...@gmail.com On Sun, Sep 16, 2012 at 10:26 AM, Gregory Beaty greg.bea...@gmail.comwrote: 1. Wix supports same version major upgrades that are the same version using the SameVersion flag. Why isn't Burn using this as well, or is there a way to turn it on? Greg Beaty greg.bea...@gmail.com On Fri, Sep 14, 2012 at 1:01 AM, Rob Mensching r...@robmensching.comwrote: 1. Bundles with the same UpgradeCode have an upgrade relationship.The higher version removes the lower version. Same versions but built at different times can end up in the situation you describe. 2. There should be very few differences between gettinga BA written for NETFX 3.5 vs. 4.0. Actually installing the NETFX 3.5 may be trickier but creating an ExePackage and referencing that via the WixMbaPrereqPackageId is all the same. On Thu, Sep 13, 2012 at 9:18 PM, Gregory Beaty gbe...@spsu.edu wrote: Thanks Rob. I do have another issue. How do I disable the ability for the BA to install multiple versions of my application? It seems that during an upgrade it installs an entirely new app and there ends up being multiple entries in Add/Remove programs. Are there any examples of a managed BA for .Net 3.5? It seems like no matter how I bundle the .Net package, author the bundle, and configure the app.config file I can not get the BA to effectively install the framework then my application. It installs the framework then it opens the the UI shell used for the framework install again and never installs my program. My application is instead replaced by UI shell that the framework installer uses. Does that make sense, and if so is that a bug? *Thanks, Greg Beaty * *LinkedIn http://www.linkedin.com/pub/gregory-beaty-jr/42/b6a/a96 | Personal http://goog_419374978**Website http://www.gregbeaty.net/ | ** gbe...@spsu.edu* On Thu, Sep 13, 2012 at 10:21 PM, Rob Mensching r...@robmensching.com wrote: The RelatedOption.None is how you know. In WiX v3.7 you also get the relation type which will further inform you that you have a related Bundle that is an upgrade but it's operation is None (i.e not upgrade and not downgrade). On Thu, Sep 13, 2012 at 4:54 AM, Gregory Beaty greg.bea...@gmail.com wrote: Hello, My WiX MSI package allows same version upgrades with: MajorUpgrade Schedule=afterInstallInitialize AllowSameVersionUpgrades=yes DowngradeErrorMessage=A newer version of [ProductName] is already installed. /. However when using this with my Manager Bootstrapper Application I never get the RelatedOperation of a MinorUpgrade or MajorUpgrade in the DetectRelatedBundle event. I only get RelatedOption.None. The process indeed upgrades the previous installation but this hinders my ability to inform the user inside of the Bootstrapper Application that the install is an upgrade. Is this a bug or is there something I am doing wrong? Is the problem that the package actions aren't scheduled until it is actually executing? Greg Beaty g gbe...@spsu.edureg.bea...@gmail.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching http://RobMensching.com LLC -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ WiX-users mailing list WiX-users@lists.sourceforge.net
Re: [WiX-users] Bootstrapper Upgrade Detection
Burn doesn't support same version upgrades, I have questioned this before as I think it should. I thought I had raised this as a bug/feature request but can't find it now. Neil -Original Message- From: Gregory Beaty [mailto:greg.bea...@gmail.com] Sent: 16 September 2012 15:27 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bootstrapper Upgrade Detection 1. Wix supports same version major upgrades that are the same version using the SameVersion flag. Why isn't Burn using this as well, or is there a way to turn it on? Greg Beaty greg.bea...@gmail.com On Fri, Sep 14, 2012 at 1:01 AM, Rob Mensching r...@robmensching.com wrote: 1. Bundles with the same UpgradeCode have an upgrade relationship.The higher version removes the lower version. Same versions but built at different times can end up in the situation you describe. 2. There should be very few differences between gettinga BA written for NETFX 3.5 vs. 4.0. Actually installing the NETFX 3.5 may be trickier but creating an ExePackage and referencing that via the WixMbaPrereqPackageId is all the same. On Thu, Sep 13, 2012 at 9:18 PM, Gregory Beaty gbe...@spsu.edu wrote: Thanks Rob. I do have another issue. How do I disable the ability for the BA to install multiple versions of my application? It seems that during an upgrade it installs an entirely new app and there ends up being multiple entries in Add/Remove programs. Are there any examples of a managed BA for .Net 3.5? It seems like no matter how I bundle the .Net package, author the bundle, and configure the app.config file I can not get the BA to effectively install the framework then my application. It installs the framework then it opens the the UI shell used for the framework install again and never installs my program. My application is instead replaced by UI shell that the framework installer uses. Does that make sense, and if so is that a bug? *Thanks, Greg Beaty * *LinkedIn http://www.linkedin.com/pub/gregory-beaty-jr/42/b6a/a96 | Personal http://goog_419374978**Website http://www.gregbeaty.net/ | ** gbe...@spsu.edu* On Thu, Sep 13, 2012 at 10:21 PM, Rob Mensching r...@robmensching.com wrote: The RelatedOption.None is how you know. In WiX v3.7 you also get the relation type which will further inform you that you have a related Bundle that is an upgrade but it's operation is None (i.e not upgrade and not downgrade). On Thu, Sep 13, 2012 at 4:54 AM, Gregory Beaty greg.bea...@gmail.com wrote: Hello, My WiX MSI package allows same version upgrades with: MajorUpgrade Schedule=afterInstallInitialize AllowSameVersionUpgrades=yes DowngradeErrorMessage=A newer version of [ProductName] is already installed. /. However when using this with my Manager Bootstrapper Application I never get the RelatedOperation of a MinorUpgrade or MajorUpgrade in the DetectRelatedBundle event. I only get RelatedOption.None. The process indeed upgrades the previous installation but this hinders my ability to inform the user inside of the Bootstrapper Application that the install is an upgrade. Is this a bug or is there something I am doing wrong? Is the problem that the package actions aren't scheduled until it is actually executing? Greg Beaty g gbe...@spsu.edureg.bea...@gmail.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching http://RobMensching.com LLC -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk
Re: [WiX-users] Bootstrapper Upgrade Detection
For info; this is the bug report http://sourceforge.net/p/wix/bugs/3065/ -Original Message- From: Neil Sleightholm [mailto:n...@x2systems.com] Sent: 16 September 2012 17:17 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bootstrapper Upgrade Detection Burn doesn't support same version upgrades, I have questioned this before as I think it should. I thought I had raised this as a bug/feature request but can't find it now. Neil -Original Message- From: Gregory Beaty [mailto:greg.bea...@gmail.com] Sent: 16 September 2012 15:27 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bootstrapper Upgrade Detection 1. Wix supports same version major upgrades that are the same version using the SameVersion flag. Why isn't Burn using this as well, or is there a way to turn it on? Greg Beaty greg.bea...@gmail.com On Fri, Sep 14, 2012 at 1:01 AM, Rob Mensching r...@robmensching.com wrote: 1. Bundles with the same UpgradeCode have an upgrade relationship.The higher version removes the lower version. Same versions but built at different times can end up in the situation you describe. 2. There should be very few differences between gettinga BA written for NETFX 3.5 vs. 4.0. Actually installing the NETFX 3.5 may be trickier but creating an ExePackage and referencing that via the WixMbaPrereqPackageId is all the same. On Thu, Sep 13, 2012 at 9:18 PM, Gregory Beaty gbe...@spsu.edu wrote: Thanks Rob. I do have another issue. How do I disable the ability for the BA to install multiple versions of my application? It seems that during an upgrade it installs an entirely new app and there ends up being multiple entries in Add/Remove programs. Are there any examples of a managed BA for .Net 3.5? It seems like no matter how I bundle the .Net package, author the bundle, and configure the app.config file I can not get the BA to effectively install the framework then my application. It installs the framework then it opens the the UI shell used for the framework install again and never installs my program. My application is instead replaced by UI shell that the framework installer uses. Does that make sense, and if so is that a bug? *Thanks, Greg Beaty * *LinkedIn http://www.linkedin.com/pub/gregory-beaty-jr/42/b6a/a96 | Personal http://goog_419374978**Website http://www.gregbeaty.net/ | ** gbe...@spsu.edu* On Thu, Sep 13, 2012 at 10:21 PM, Rob Mensching r...@robmensching.com wrote: The RelatedOption.None is how you know. In WiX v3.7 you also get the relation type which will further inform you that you have a related Bundle that is an upgrade but it's operation is None (i.e not upgrade and not downgrade). On Thu, Sep 13, 2012 at 4:54 AM, Gregory Beaty greg.bea...@gmail.com wrote: Hello, My WiX MSI package allows same version upgrades with: MajorUpgrade Schedule=afterInstallInitialize AllowSameVersionUpgrades=yes DowngradeErrorMessage=A newer version of [ProductName] is already installed. /. However when using this with my Manager Bootstrapper Application I never get the RelatedOperation of a MinorUpgrade or MajorUpgrade in the DetectRelatedBundle event. I only get RelatedOption.None. The process indeed upgrades the previous installation but this hinders my ability to inform the user inside of the Bootstrapper Application that the install is an upgrade. Is this a bug or is there something I am doing wrong? Is the problem that the package actions aren't scheduled until it is actually executing? Greg Beaty g gbe...@spsu.edureg.bea...@gmail.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching http://RobMensching.com LLC -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ WiX-users mailing list WiX-users@lists.sourceforge.net https
Re: [WiX-users] Bootstrapper Upgrade Detection
Even my different version upgrades don't remove the previous installed version. I seem to have problems uninstalling a previous bundle from an upgraded bundle. I believe the logs always indicate there is a dependency which can't be possible since I only have one MSI package in the chain. This kind of leads me to believe that Burn handles repairs differently as well. In my old bootstrapper repairs worked fine, but when using Burn it seems that the StopServices action is never called and instead WixRemoveFoldersEx is called which introduces issues with my application because my service has exclusive locks on some files. Greg Beaty greg.bea...@gmail.com On Sun, Sep 16, 2012 at 12:17 PM, Neil Sleightholm n...@x2systems.comwrote: Burn doesn't support same version upgrades, I have questioned this before as I think it should. I thought I had raised this as a bug/feature request but can't find it now. Neil -Original Message- From: Gregory Beaty [mailto:greg.bea...@gmail.com] Sent: 16 September 2012 15:27 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bootstrapper Upgrade Detection 1. Wix supports same version major upgrades that are the same version using the SameVersion flag. Why isn't Burn using this as well, or is there a way to turn it on? Greg Beaty greg.bea...@gmail.com On Fri, Sep 14, 2012 at 1:01 AM, Rob Mensching r...@robmensching.com wrote: 1. Bundles with the same UpgradeCode have an upgrade relationship.The higher version removes the lower version. Same versions but built at different times can end up in the situation you describe. 2. There should be very few differences between gettinga BA written for NETFX 3.5 vs. 4.0. Actually installing the NETFX 3.5 may be trickier but creating an ExePackage and referencing that via the WixMbaPrereqPackageId is all the same. On Thu, Sep 13, 2012 at 9:18 PM, Gregory Beaty gbe...@spsu.edu wrote: Thanks Rob. I do have another issue. How do I disable the ability for the BA to install multiple versions of my application? It seems that during an upgrade it installs an entirely new app and there ends up being multiple entries in Add/Remove programs. Are there any examples of a managed BA for .Net 3.5? It seems like no matter how I bundle the .Net package, author the bundle, and configure the app.config file I can not get the BA to effectively install the framework then my application. It installs the framework then it opens the the UI shell used for the framework install again and never installs my program. My application is instead replaced by UI shell that the framework installer uses. Does that make sense, and if so is that a bug? *Thanks, Greg Beaty * *LinkedIn http://www.linkedin.com/pub/gregory-beaty-jr/42/b6a/a96 | Personal http://goog_419374978**Website http://www.gregbeaty.net/ | ** gbe...@spsu.edu* On Thu, Sep 13, 2012 at 10:21 PM, Rob Mensching r...@robmensching.com wrote: The RelatedOption.None is how you know. In WiX v3.7 you also get the relation type which will further inform you that you have a related Bundle that is an upgrade but it's operation is None (i.e not upgrade and not downgrade). On Thu, Sep 13, 2012 at 4:54 AM, Gregory Beaty greg.bea...@gmail.com wrote: Hello, My WiX MSI package allows same version upgrades with: MajorUpgrade Schedule=afterInstallInitialize AllowSameVersionUpgrades=yes DowngradeErrorMessage=A newer version of [ProductName] is already installed. /. However when using this with my Manager Bootstrapper Application I never get the RelatedOperation of a MinorUpgrade or MajorUpgrade in the DetectRelatedBundle event. I only get RelatedOption.None. The process indeed upgrades the previous installation but this hinders my ability to inform the user inside of the Bootstrapper Application that the install is an upgrade. Is this a bug or is there something I am doing wrong? Is the problem that the package actions aren't scheduled until it is actually executing? Greg Beaty g gbe...@spsu.edureg.bea...@gmail.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually
Re: [WiX-users] Bootstrapper Upgrade Detection
Thanks for the reference. Greg Beaty greg.bea...@gmail.com On Sun, Sep 16, 2012 at 12:35 PM, Gregory Beaty greg.bea...@gmail.comwrote: Even my different version upgrades don't remove the previous installed version. I seem to have problems uninstalling a previous bundle from an upgraded bundle. I believe the logs always indicate there is a dependency which can't be possible since I only have one MSI package in the chain. This kind of leads me to believe that Burn handles repairs differently as well. In my old bootstrapper repairs worked fine, but when using Burn it seems that the StopServices action is never called and instead WixRemoveFoldersEx is called which introduces issues with my application because my service has exclusive locks on some files. Greg Beaty greg.bea...@gmail.com On Sun, Sep 16, 2012 at 12:17 PM, Neil Sleightholm n...@x2systems.comwrote: Burn doesn't support same version upgrades, I have questioned this before as I think it should. I thought I had raised this as a bug/feature request but can't find it now. Neil -Original Message- From: Gregory Beaty [mailto:greg.bea...@gmail.com] Sent: 16 September 2012 15:27 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bootstrapper Upgrade Detection 1. Wix supports same version major upgrades that are the same version using the SameVersion flag. Why isn't Burn using this as well, or is there a way to turn it on? Greg Beaty greg.bea...@gmail.com On Fri, Sep 14, 2012 at 1:01 AM, Rob Mensching r...@robmensching.com wrote: 1. Bundles with the same UpgradeCode have an upgrade relationship.The higher version removes the lower version. Same versions but built at different times can end up in the situation you describe. 2. There should be very few differences between gettinga BA written for NETFX 3.5 vs. 4.0. Actually installing the NETFX 3.5 may be trickier but creating an ExePackage and referencing that via the WixMbaPrereqPackageId is all the same. On Thu, Sep 13, 2012 at 9:18 PM, Gregory Beaty gbe...@spsu.edu wrote: Thanks Rob. I do have another issue. How do I disable the ability for the BA to install multiple versions of my application? It seems that during an upgrade it installs an entirely new app and there ends up being multiple entries in Add/Remove programs. Are there any examples of a managed BA for .Net 3.5? It seems like no matter how I bundle the .Net package, author the bundle, and configure the app.config file I can not get the BA to effectively install the framework then my application. It installs the framework then it opens the the UI shell used for the framework install again and never installs my program. My application is instead replaced by UI shell that the framework installer uses. Does that make sense, and if so is that a bug? *Thanks, Greg Beaty * *LinkedIn http://www.linkedin.com/pub/gregory-beaty-jr/42/b6a/a96 | Personal http://goog_419374978**Website http://www.gregbeaty.net/ | ** gbe...@spsu.edu* On Thu, Sep 13, 2012 at 10:21 PM, Rob Mensching r...@robmensching.com wrote: The RelatedOption.None is how you know. In WiX v3.7 you also get the relation type which will further inform you that you have a related Bundle that is an upgrade but it's operation is None (i.e not upgrade and not downgrade). On Thu, Sep 13, 2012 at 4:54 AM, Gregory Beaty greg.bea...@gmail.com wrote: Hello, My WiX MSI package allows same version upgrades with: MajorUpgrade Schedule=afterInstallInitialize AllowSameVersionUpgrades=yes DowngradeErrorMessage=A newer version of [ProductName] is already installed. /. However when using this with my Manager Bootstrapper Application I never get the RelatedOperation of a MinorUpgrade or MajorUpgrade in the DetectRelatedBundle event. I only get RelatedOption.None. The process indeed upgrades the previous installation but this hinders my ability to inform the user inside of the Bootstrapper Application that the install is an upgrade. Is this a bug or is there something I am doing wrong? Is the problem that the package actions aren't scheduled until it is actually executing? Greg Beaty g gbe...@spsu.edureg.bea...@gmail.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing
Re: [WiX-users] Bootstrapper Upgrade Detection
I had this issue when I had done some same version installs and then started changing the version; the cause was multiple entries in ARP. It might we worth checking this, I found if I removed all the versions then the upgrades started working. Neil -Original Message- From: Gregory Beaty [mailto:greg.bea...@gmail.com] Sent: 16 September 2012 17:36 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bootstrapper Upgrade Detection Even my different version upgrades don't remove the previous installed version. I seem to have problems uninstalling a previous bundle from an upgraded bundle. I believe the logs always indicate there is a dependency which can't be possible since I only have one MSI package in the chain. This kind of leads me to believe that Burn handles repairs differently as well. In my old bootstrapper repairs worked fine, but when using Burn it seems that the StopServices action is never called and instead WixRemoveFoldersEx is called which introduces issues with my application because my service has exclusive locks on some files. Greg Beaty greg.bea...@gmail.com On Sun, Sep 16, 2012 at 12:17 PM, Neil Sleightholm n...@x2systems.comwrote: Burn doesn't support same version upgrades, I have questioned this before as I think it should. I thought I had raised this as a bug/feature request but can't find it now. Neil -Original Message- From: Gregory Beaty [mailto:greg.bea...@gmail.com] Sent: 16 September 2012 15:27 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bootstrapper Upgrade Detection 1. Wix supports same version major upgrades that are the same version using the SameVersion flag. Why isn't Burn using this as well, or is there a way to turn it on? Greg Beaty greg.bea...@gmail.com On Fri, Sep 14, 2012 at 1:01 AM, Rob Mensching r...@robmensching.com wrote: 1. Bundles with the same UpgradeCode have an upgrade relationship.The higher version removes the lower version. Same versions but built at different times can end up in the situation you describe. 2. There should be very few differences between gettinga BA written for NETFX 3.5 vs. 4.0. Actually installing the NETFX 3.5 may be trickier but creating an ExePackage and referencing that via the WixMbaPrereqPackageId is all the same. On Thu, Sep 13, 2012 at 9:18 PM, Gregory Beaty gbe...@spsu.edu wrote: Thanks Rob. I do have another issue. How do I disable the ability for the BA to install multiple versions of my application? It seems that during an upgrade it installs an entirely new app and there ends up being multiple entries in Add/Remove programs. Are there any examples of a managed BA for .Net 3.5? It seems like no matter how I bundle the .Net package, author the bundle, and configure the app.config file I can not get the BA to effectively install the framework then my application. It installs the framework then it opens the the UI shell used for the framework install again and never installs my program. My application is instead replaced by UI shell that the framework installer uses. Does that make sense, and if so is that a bug? *Thanks, Greg Beaty * *LinkedIn http://www.linkedin.com/pub/gregory-beaty-jr/42/b6a/a96 | Personal http://goog_419374978**Website http://www.gregbeaty.net/ | ** gbe...@spsu.edu* On Thu, Sep 13, 2012 at 10:21 PM, Rob Mensching r...@robmensching.com wrote: The RelatedOption.None is how you know. In WiX v3.7 you also get the relation type which will further inform you that you have a related Bundle that is an upgrade but it's operation is None (i.e not upgrade and not downgrade). On Thu, Sep 13, 2012 at 4:54 AM, Gregory Beaty greg.bea...@gmail.com wrote: Hello, My WiX MSI package allows same version upgrades with: MajorUpgrade Schedule=afterInstallInitialize AllowSameVersionUpgrades=yes DowngradeErrorMessage=A newer version of [ProductName] is already installed. /. However when using this with my Manager Bootstrapper Application I never get the RelatedOperation of a MinorUpgrade or MajorUpgrade in the DetectRelatedBundle event. I only get RelatedOption.None. The process indeed upgrades the previous installation but this hinders my ability to inform the user inside of the Bootstrapper Application that the install is an upgrade. Is this a bug or is there something I am doing wrong? Is the problem that the package actions aren't scheduled until it is actually executing? Greg Beaty g gbe...@spsu.edureg.bea...@gmail.com -- Live Security Virtual Conference Exclusive
Re: [WiX-users] Bootstrapper Upgrade Detection
Does this mean I should remove the AllowSameVersions from the MajorUpgrade tag also? Right now I still get multiple entries with different versions but I still have the flag there. Greg Beaty greg.bea...@gmail.com On Sun, Sep 16, 2012 at 12:41 PM, Neil Sleightholm n...@x2systems.comwrote: I had this issue when I had done some same version installs and then started changing the version; the cause was multiple entries in ARP. It might we worth checking this, I found if I removed all the versions then the upgrades started working. Neil -Original Message- From: Gregory Beaty [mailto:greg.bea...@gmail.com] Sent: 16 September 2012 17:36 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bootstrapper Upgrade Detection Even my different version upgrades don't remove the previous installed version. I seem to have problems uninstalling a previous bundle from an upgraded bundle. I believe the logs always indicate there is a dependency which can't be possible since I only have one MSI package in the chain. This kind of leads me to believe that Burn handles repairs differently as well. In my old bootstrapper repairs worked fine, but when using Burn it seems that the StopServices action is never called and instead WixRemoveFoldersEx is called which introduces issues with my application because my service has exclusive locks on some files. Greg Beaty greg.bea...@gmail.com On Sun, Sep 16, 2012 at 12:17 PM, Neil Sleightholm n...@x2systems.com wrote: Burn doesn't support same version upgrades, I have questioned this before as I think it should. I thought I had raised this as a bug/feature request but can't find it now. Neil -Original Message- From: Gregory Beaty [mailto:greg.bea...@gmail.com] Sent: 16 September 2012 15:27 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bootstrapper Upgrade Detection 1. Wix supports same version major upgrades that are the same version using the SameVersion flag. Why isn't Burn using this as well, or is there a way to turn it on? Greg Beaty greg.bea...@gmail.com On Fri, Sep 14, 2012 at 1:01 AM, Rob Mensching r...@robmensching.com wrote: 1. Bundles with the same UpgradeCode have an upgrade relationship.The higher version removes the lower version. Same versions but built at different times can end up in the situation you describe. 2. There should be very few differences between gettinga BA written for NETFX 3.5 vs. 4.0. Actually installing the NETFX 3.5 may be trickier but creating an ExePackage and referencing that via the WixMbaPrereqPackageId is all the same. On Thu, Sep 13, 2012 at 9:18 PM, Gregory Beaty gbe...@spsu.edu wrote: Thanks Rob. I do have another issue. How do I disable the ability for the BA to install multiple versions of my application? It seems that during an upgrade it installs an entirely new app and there ends up being multiple entries in Add/Remove programs. Are there any examples of a managed BA for .Net 3.5? It seems like no matter how I bundle the .Net package, author the bundle, and configure the app.config file I can not get the BA to effectively install the framework then my application. It installs the framework then it opens the the UI shell used for the framework install again and never installs my program. My application is instead replaced by UI shell that the framework installer uses. Does that make sense, and if so is that a bug? *Thanks, Greg Beaty * *LinkedIn http://www.linkedin.com/pub/gregory-beaty-jr/42/b6a/a96 | Personal http://goog_419374978**Website http://www.gregbeaty.net/ | ** gbe...@spsu.edu* On Thu, Sep 13, 2012 at 10:21 PM, Rob Mensching r...@robmensching.com wrote: The RelatedOption.None is how you know. In WiX v3.7 you also get the relation type which will further inform you that you have a related Bundle that is an upgrade but it's operation is None (i.e not upgrade and not downgrade). On Thu, Sep 13, 2012 at 4:54 AM, Gregory Beaty greg.bea...@gmail.com wrote: Hello, My WiX MSI package allows same version upgrades with: MajorUpgrade Schedule=afterInstallInitialize AllowSameVersionUpgrades=yes DowngradeErrorMessage=A newer version of [ProductName] is already installed. /. However when using this with my Manager Bootstrapper Application I never get the RelatedOperation of a MinorUpgrade or MajorUpgrade in the DetectRelatedBundle event. I only get RelatedOption.None. The process indeed upgrades the previous installation but this hinders my ability to inform the user inside of the Bootstrapper Application that the install is an upgrade
[WiX-users] Bootstrapper Upgrade Detection
Hello, My WiX MSI package allows same version upgrades with: MajorUpgrade Schedule=afterInstallInitialize AllowSameVersionUpgrades=yes DowngradeErrorMessage=A newer version of [ProductName] is already installed. /. However when using this with my Manager Bootstrapper Application I never get the RelatedOperation of a MinorUpgrade or MajorUpgrade in the DetectRelatedBundle event. I only get RelatedOption.None. The process indeed upgrades the previous installation but this hinders my ability to inform the user inside of the Bootstrapper Application that the install is an upgrade. Is this a bug or is there something I am doing wrong? Is the problem that the package actions aren't scheduled until it is actually executing? Greg Beaty g gbe...@spsu.edureg.bea...@gmail.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bootstrapper Upgrade Detection
The RelatedOption.None is how you know. In WiX v3.7 you also get the relation type which will further inform you that you have a related Bundle that is an upgrade but it's operation is None (i.e not upgrade and not downgrade). On Thu, Sep 13, 2012 at 4:54 AM, Gregory Beaty greg.bea...@gmail.comwrote: Hello, My WiX MSI package allows same version upgrades with: MajorUpgrade Schedule=afterInstallInitialize AllowSameVersionUpgrades=yes DowngradeErrorMessage=A newer version of [ProductName] is already installed. /. However when using this with my Manager Bootstrapper Application I never get the RelatedOperation of a MinorUpgrade or MajorUpgrade in the DetectRelatedBundle event. I only get RelatedOption.None. The process indeed upgrades the previous installation but this hinders my ability to inform the user inside of the Bootstrapper Application that the install is an upgrade. Is this a bug or is there something I am doing wrong? Is the problem that the package actions aren't scheduled until it is actually executing? Greg Beaty g gbe...@spsu.edureg.bea...@gmail.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching http://RobMensching.com LLC -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bootstrapper Upgrade Detection
Thanks Rob. I do have another issue. How do I disable the ability for the BA to install multiple versions of my application? It seems that during an upgrade it installs an entirely new app and there ends up being multiple entries in Add/Remove programs. Are there any examples of a managed BA for .Net 3.5? It seems like no matter how I bundle the .Net package, author the bundle, and configure the app.config file I can not get the BA to effectively install the framework then my application. It installs the framework then it opens the the UI shell used for the framework install again and never installs my program. My application is instead replaced by UI shell that the framework installer uses. Does that make sense, and if so is that a bug? *Thanks, Greg Beaty * *LinkedIn http://www.linkedin.com/pub/gregory-beaty-jr/42/b6a/a96 | Personal http://goog_419374978**Website http://www.gregbeaty.net/ | ** gbe...@spsu.edu* On Thu, Sep 13, 2012 at 10:21 PM, Rob Mensching r...@robmensching.comwrote: The RelatedOption.None is how you know. In WiX v3.7 you also get the relation type which will further inform you that you have a related Bundle that is an upgrade but it's operation is None (i.e not upgrade and not downgrade). On Thu, Sep 13, 2012 at 4:54 AM, Gregory Beaty greg.bea...@gmail.com wrote: Hello, My WiX MSI package allows same version upgrades with: MajorUpgrade Schedule=afterInstallInitialize AllowSameVersionUpgrades=yes DowngradeErrorMessage=A newer version of [ProductName] is already installed. /. However when using this with my Manager Bootstrapper Application I never get the RelatedOperation of a MinorUpgrade or MajorUpgrade in the DetectRelatedBundle event. I only get RelatedOption.None. The process indeed upgrades the previous installation but this hinders my ability to inform the user inside of the Bootstrapper Application that the install is an upgrade. Is this a bug or is there something I am doing wrong? Is the problem that the package actions aren't scheduled until it is actually executing? Greg Beaty g gbe...@spsu.edureg.bea...@gmail.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching http://RobMensching.com LLC -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bootstrapper Upgrade Detection
Thanks Rob. I do have another issue. How do I disable the ability for the BA to install multiple versions of my application? It seems that during an upgrade it installs an entirely new app and there ends up being multiple entries in Add/Remove programs. Are there any examples of a managed BA for .Net 3.5? It seems like no matter how I bundle the .Net package, author the bundle, and configure the app.config file I can not get the BA to effectively install the framework then my application. It installs the framework then it opens the the UI shell used for the framework install again and never installs my program. My application is instead replaced by UI shell that the framework installer uses. Does that make sense, and if so is that a bug? Greg Beaty greg.bea...@gmail.com On Thu, Sep 13, 2012 at 10:21 PM, Rob Mensching r...@robmensching.comwrote: The RelatedOption.None is how you know. In WiX v3.7 you also get the relation type which will further inform you that you have a related Bundle that is an upgrade but it's operation is None (i.e not upgrade and not downgrade). On Thu, Sep 13, 2012 at 4:54 AM, Gregory Beaty greg.bea...@gmail.com wrote: Hello, My WiX MSI package allows same version upgrades with: MajorUpgrade Schedule=afterInstallInitialize AllowSameVersionUpgrades=yes DowngradeErrorMessage=A newer version of [ProductName] is already installed. /. However when using this with my Manager Bootstrapper Application I never get the RelatedOperation of a MinorUpgrade or MajorUpgrade in the DetectRelatedBundle event. I only get RelatedOption.None. The process indeed upgrades the previous installation but this hinders my ability to inform the user inside of the Bootstrapper Application that the install is an upgrade. Is this a bug or is there something I am doing wrong? Is the problem that the package actions aren't scheduled until it is actually executing? Greg Beaty g gbe...@spsu.edureg.bea...@gmail.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching http://RobMensching.com LLC -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bootstrapper Upgrade Detection
Sorry for the double post. Greg Beaty greg.bea...@gmail.com On Fri, Sep 14, 2012 at 12:19 AM, Gregory Beaty greg.bea...@gmail.comwrote: Thanks Rob. I do have another issue. How do I disable the ability for the BA to install multiple versions of my application? It seems that during an upgrade it installs an entirely new app and there ends up being multiple entries in Add/Remove programs. Are there any examples of a managed BA for .Net 3.5? It seems like no matter how I bundle the .Net package, author the bundle, and configure the app.config file I can not get the BA to effectively install the framework then my application. It installs the framework then it opens the the UI shell used for the framework install again and never installs my program. My application is instead replaced by UI shell that the framework installer uses. Does that make sense, and if so is that a bug? Greg Beaty greg.bea...@gmail.com On Thu, Sep 13, 2012 at 10:21 PM, Rob Mensching r...@robmensching.comwrote: The RelatedOption.None is how you know. In WiX v3.7 you also get the relation type which will further inform you that you have a related Bundle that is an upgrade but it's operation is None (i.e not upgrade and not downgrade). On Thu, Sep 13, 2012 at 4:54 AM, Gregory Beaty greg.bea...@gmail.com wrote: Hello, My WiX MSI package allows same version upgrades with: MajorUpgrade Schedule=afterInstallInitialize AllowSameVersionUpgrades=yes DowngradeErrorMessage=A newer version of [ProductName] is already installed. /. However when using this with my Manager Bootstrapper Application I never get the RelatedOperation of a MinorUpgrade or MajorUpgrade in the DetectRelatedBundle event. I only get RelatedOption.None. The process indeed upgrades the previous installation but this hinders my ability to inform the user inside of the Bootstrapper Application that the install is an upgrade. Is this a bug or is there something I am doing wrong? Is the problem that the package actions aren't scheduled until it is actually executing? Greg Beaty g gbe...@spsu.edureg.bea...@gmail.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching http://RobMensching.com LLC -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bootstrapper Upgrade Detection
1. Bundles with the same UpgradeCode have an upgrade relationship.The higher version removes the lower version. Same versions but built at different times can end up in the situation you describe. 2. There should be very few differences between gettinga BA written for NETFX 3.5 vs. 4.0. Actually installing the NETFX 3.5 may be trickier but creating an ExePackage and referencing that via the WixMbaPrereqPackageId is all the same. On Thu, Sep 13, 2012 at 9:18 PM, Gregory Beaty gbe...@spsu.edu wrote: Thanks Rob. I do have another issue. How do I disable the ability for the BA to install multiple versions of my application? It seems that during an upgrade it installs an entirely new app and there ends up being multiple entries in Add/Remove programs. Are there any examples of a managed BA for .Net 3.5? It seems like no matter how I bundle the .Net package, author the bundle, and configure the app.config file I can not get the BA to effectively install the framework then my application. It installs the framework then it opens the the UI shell used for the framework install again and never installs my program. My application is instead replaced by UI shell that the framework installer uses. Does that make sense, and if so is that a bug? *Thanks, Greg Beaty * *LinkedIn http://www.linkedin.com/pub/gregory-beaty-jr/42/b6a/a96 | Personal http://goog_419374978**Website http://www.gregbeaty.net/ | ** gbe...@spsu.edu* On Thu, Sep 13, 2012 at 10:21 PM, Rob Mensching r...@robmensching.com wrote: The RelatedOption.None is how you know. In WiX v3.7 you also get the relation type which will further inform you that you have a related Bundle that is an upgrade but it's operation is None (i.e not upgrade and not downgrade). On Thu, Sep 13, 2012 at 4:54 AM, Gregory Beaty greg.bea...@gmail.com wrote: Hello, My WiX MSI package allows same version upgrades with: MajorUpgrade Schedule=afterInstallInitialize AllowSameVersionUpgrades=yes DowngradeErrorMessage=A newer version of [ProductName] is already installed. /. However when using this with my Manager Bootstrapper Application I never get the RelatedOperation of a MinorUpgrade or MajorUpgrade in the DetectRelatedBundle event. I only get RelatedOption.None. The process indeed upgrades the previous installation but this hinders my ability to inform the user inside of the Bootstrapper Application that the install is an upgrade. Is this a bug or is there something I am doing wrong? Is the problem that the package actions aren't scheduled until it is actually executing? Greg Beaty g gbe...@spsu.edureg.bea...@gmail.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching http://RobMensching.com LLC -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching http://RobMensching.com LLC -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
