Re: [WiX-users] Upgrade confusion
Thank you for the missing link, I am now able to detect this as I
wanted.
I have a new problem though. When the upgraded/new version of
bootstrapper is invoked through the Update command, I am running into an
issue where the app is trying to see what version it is by using
Assembly/FileVersionInfo, but it is looking for its files in the wrong
place (C:\Users\x\AppData\Local\Package Cache\) as opposed to
(C:\ProgramData\Package Cache) and is causing a
System.IO.FileNotFoundException.
Can anyone explain why it can't find itself? I've tried toggling the
Cache="yes" property but nothing changes.
=Details=
v1.0.73 Installed. Exists: C:\ProgramData\Package
Cache\{971e0d36-1c42-4eca-a6ee-4804edcc83eb}\MyApp.exe
v1.0.73 Change, Update v1.0.74 Launched:
This gets created, but is empty: C:\Users\dirt\AppData\Local\Package
Cache\{971e0d36-1c42-4eca-a6ee-4804edcc83eb}
System.FileNotFoundException: C:\Users\dirt\AppData\Local\Package
Cache\{971e0d36-1c42-4eca-a6ee-4804edcc83eb}\MyApp.exe
=
Thanks,
-dirt
On 2013-10-14 10:35, Hoover, Jacob wrote:
> The engine is going to have "burn.related.upgrade" passed as a
> command line option, but as that is an internal burn parameter it
> won't get passed to your BA. The engine does set
> pCommand->relationType = BOOTSTRAPPER_RELATION_UPGRADE;
>
> Take a look at Command.Relation.
>
> -Original Message-
> From: dirt [mailto:d...@awoms.com]
> Sent: Monday, October 14, 2013 9:21 AM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Upgrade confusion
>
> When a bootstrapper v1.0.1 downloads and installs an update (v1.0.2)
> it logs "Automatically closing the window since update successful" and
> opens the v1.0.2 bootstrapper with this in the log at the top:
>
> "This bundle is being run by a related bundle as type 'Update'."
>
> From what I can tell in the logs, when the v1.0.2 is opened it is
> treated just like a normal run; the Action is "Install".
>
>
> Is there any built-in way to detect when a bootstrapper is ran as type
> 'Update'?
>
>
> The only way I see how to do this currently would be to store
> something
> in the registry at the shutdown of v1 that v2 reads to know that it
> should automatically continue to the Install portion.
>
> Thanks,
> -dirt
>
> On 2013-10-11 15:58, dirt wrote:
>> How am I to detect that the bootstrapper has been invoked via an
>> Update
>> and thus should suppress the UI and auto-invoke the Install sequence?
>>
>> I dont see anything when comparing the 1.0.1 and 1.0.2 logs to
>> indicate
>> that an Update could be detected. There is one line at the top of the
>> v1.0.2 log: i003: This bundle is being run by a related bundle as
>> type
>> 'Update'.
>>
>> But in DetectBegin the CustomBA.Model.Bootstrapper.Command.Action is
>> "Install", when I would expect it to be "UpdateReplace".
>>
>> =
>> Using Burn v3.8.1007.0.
>> PID is *.
>> Version Build is incremented on each build.
>> =
>>
>> v1.0.1 Installed
>> v1.0.1 Change launched from ARP, Update clicked, v1.0.2 downloaded
>> and
>> ExecutePackageComplete is success, v1.0.1 is exited automatically
>> v1.0.2 Is auto opened, but instead of detecting it is an update and
>> auto installing, it appears in the logs that the bootstrapper and
>> MyApp
>> are detected as Absent and it sits at the UI waiting for you to click
>> Install.
>>
>> Thanks,
>> -dirt
>>
>> On 2013-10-11 11:57, dirt wrote:
>>> Thank you for the clarification.
>>>
>>> I have made progress and here is an updated scenario, I am not sure
>>> why
>>> the update is not auto-installing but instead waiting for me to
>>> click
>>> Install (at step 2)
>>>
>>> =
>>> Product ID = *
>>> Product UpgradeCode = 029B...BD97
>>> Bootstrapper UpgradeCode = f031...56b3
>>> =
>>>
>>> 1) Install Bootstrapper v1.0.1
>>>
>>> 2) Run Add/Remove Programs > Change, Launches v1.0.1 UI, Click
>>> Update
>>>
>>> Update downloads, runs, appears to install and close the original UI
>>> (v1.0.1) and opens the new UI (v1.0.2)
>>>
>>> UI shows new version and shows as "Not Installed" with the Install
>>> option enabled.
>>>
>>> =
>>> This bundle is being run by a related bundle as type 'Update'.
>>> DetectBegin: Not Installed
>>> Detected package: MyApp,
Re: [WiX-users] Upgrade confusion
The engine is going to have "burn.related.upgrade" passed as a command line option, but as that is an internal burn parameter it won't get passed to your BA. The engine does set pCommand->relationType = BOOTSTRAPPER_RELATION_UPGRADE; Take a look at Command.Relation. -Original Message- From: dirt [mailto:d...@awoms.com] Sent: Monday, October 14, 2013 9:21 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Upgrade confusion When a bootstrapper v1.0.1 downloads and installs an update (v1.0.2) it logs "Automatically closing the window since update successful" and opens the v1.0.2 bootstrapper with this in the log at the top: "This bundle is being run by a related bundle as type 'Update'." From what I can tell in the logs, when the v1.0.2 is opened it is treated just like a normal run; the Action is "Install". Is there any built-in way to detect when a bootstrapper is ran as type 'Update'? The only way I see how to do this currently would be to store something in the registry at the shutdown of v1 that v2 reads to know that it should automatically continue to the Install portion. Thanks, -dirt On 2013-10-11 15:58, dirt wrote: > How am I to detect that the bootstrapper has been invoked via an > Update > and thus should suppress the UI and auto-invoke the Install sequence? > > I dont see anything when comparing the 1.0.1 and 1.0.2 logs to > indicate > that an Update could be detected. There is one line at the top of the > v1.0.2 log: i003: This bundle is being run by a related bundle as type > 'Update'. > > But in DetectBegin the CustomBA.Model.Bootstrapper.Command.Action is > "Install", when I would expect it to be "UpdateReplace". > > = > Using Burn v3.8.1007.0. > PID is *. > Version Build is incremented on each build. > = > > v1.0.1 Installed > v1.0.1 Change launched from ARP, Update clicked, v1.0.2 downloaded and > ExecutePackageComplete is success, v1.0.1 is exited automatically > v1.0.2 Is auto opened, but instead of detecting it is an update and > auto installing, it appears in the logs that the bootstrapper and > MyApp > are detected as Absent and it sits at the UI waiting for you to click > Install. > > Thanks, > -dirt > > On 2013-10-11 11:57, dirt wrote: >> Thank you for the clarification. >> >> I have made progress and here is an updated scenario, I am not sure >> why >> the update is not auto-installing but instead waiting for me to click >> Install (at step 2) >> >> = >> Product ID = * >> Product UpgradeCode = 029B...BD97 >> Bootstrapper UpgradeCode = f031...56b3 >> = >> >> 1) Install Bootstrapper v1.0.1 >> >> 2) Run Add/Remove Programs > Change, Launches v1.0.1 UI, Click Update >> >> Update downloads, runs, appears to install and close the original UI >> (v1.0.1) and opens the new UI (v1.0.2) >> >> UI shows new version and shows as "Not Installed" with the Install >> option enabled. >> >> = >> This bundle is being run by a related bundle as type 'Update'. >> DetectBegin: Not Installed >> Detected package: MyApp, state: Absent >> DetectComplete: DetectedAbsent >> = >> >> ***a) Why does it not Auto Install? It is triggered by 'Update' yet >> waits for me to click Install.*** >> >> 3) Click Install: Installs MyApp >> >> v1.0.2 is installed successfully >> >> v1.0.1 ui is opened again automatically (this time appears to be >> hidden) >> >> 4) v1.0.2 UI shows as Complete. >> >> Add/Remove programs shows new v1.0.2 is installed. >> = >> >> Thanks, >> -dirt >> >> On 2013-10-10 19:08, Phill Hogland wrote: >>> For MajorUpgrade behavior you must change both the Product ID and >>> the >>> version. The UpgradeCode should remain unchanged. Also the version >>> of the >>> MSI must change in the first three quad-dots. The version of the >>> bundle can >>> be changed in any part of the version string. >>> >>> http://wixtoolset.org/documentation/manual/v3/howtos/updates/major_upgrade.html >>> >>> I would set the Id="*" and increment the Build portion of the >>> version >>> string >>> (Major.Minor.Build.Revision) to achieve what you are trying to do. >>> >>> >>> >>> -- >>> View this message in context: >>> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Upgrade-confusion-tp
Re: [WiX-users] Upgrade confusion
When a bootstrapper v1.0.1 downloads and installs an update (v1.0.2) it logs "Automatically closing the window since update successful" and opens the v1.0.2 bootstrapper with this in the log at the top: "This bundle is being run by a related bundle as type 'Update'." From what I can tell in the logs, when the v1.0.2 is opened it is treated just like a normal run; the Action is "Install". Is there any built-in way to detect when a bootstrapper is ran as type 'Update'? The only way I see how to do this currently would be to store something in the registry at the shutdown of v1 that v2 reads to know that it should automatically continue to the Install portion. Thanks, -dirt On 2013-10-11 15:58, dirt wrote: > How am I to detect that the bootstrapper has been invoked via an > Update > and thus should suppress the UI and auto-invoke the Install sequence? > > I dont see anything when comparing the 1.0.1 and 1.0.2 logs to > indicate > that an Update could be detected. There is one line at the top of the > v1.0.2 log: i003: This bundle is being run by a related bundle as type > 'Update'. > > But in DetectBegin the CustomBA.Model.Bootstrapper.Command.Action is > "Install", when I would expect it to be "UpdateReplace". > > = > Using Burn v3.8.1007.0. > PID is *. > Version Build is incremented on each build. > = > > v1.0.1 Installed > v1.0.1 Change launched from ARP, Update clicked, v1.0.2 downloaded and > ExecutePackageComplete is success, v1.0.1 is exited automatically > v1.0.2 Is auto opened, but instead of detecting it is an update and > auto installing, it appears in the logs that the bootstrapper and > MyApp > are detected as Absent and it sits at the UI waiting for you to click > Install. > > Thanks, > -dirt > > On 2013-10-11 11:57, dirt wrote: >> Thank you for the clarification. >> >> I have made progress and here is an updated scenario, I am not sure >> why >> the update is not auto-installing but instead waiting for me to click >> Install (at step 2) >> >> = >> Product ID = * >> Product UpgradeCode = 029B...BD97 >> Bootstrapper UpgradeCode = f031...56b3 >> = >> >> 1) Install Bootstrapper v1.0.1 >> >> 2) Run Add/Remove Programs > Change, Launches v1.0.1 UI, Click Update >> >> Update downloads, runs, appears to install and close the original UI >> (v1.0.1) and opens the new UI (v1.0.2) >> >> UI shows new version and shows as "Not Installed" with the Install >> option enabled. >> >> = >> This bundle is being run by a related bundle as type 'Update'. >> DetectBegin: Not Installed >> Detected package: MyApp, state: Absent >> DetectComplete: DetectedAbsent >> = >> >> ***a) Why does it not Auto Install? It is triggered by 'Update' yet >> waits for me to click Install.*** >> >> 3) Click Install: Installs MyApp >> >> v1.0.2 is installed successfully >> >> v1.0.1 ui is opened again automatically (this time appears to be >> hidden) >> >> 4) v1.0.2 UI shows as Complete. >> >> Add/Remove programs shows new v1.0.2 is installed. >> = >> >> Thanks, >> -dirt >> >> On 2013-10-10 19:08, Phill Hogland wrote: >>> For MajorUpgrade behavior you must change both the Product ID and >>> the >>> version. The UpgradeCode should remain unchanged. Also the version >>> of the >>> MSI must change in the first three quad-dots. The version of the >>> bundle can >>> be changed in any part of the version string. >>> >>> http://wixtoolset.org/documentation/manual/v3/howtos/updates/major_upgrade.html >>> >>> I would set the Id="*" and increment the Build portion of the >>> version >>> string >>> (Major.Minor.Build.Revision) to achieve what you are trying to do. >>> >>> >>> >>> -- >>> View this message in context: >>> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Upgrade-confusion-tp7589648p7589649.html >>> Sent from the wix-users mailing list archive at Nabble.com. >>> >>> -- >>> October Webinars: Code for Performance >>> Free Intel webinars can help you accelerate application performance. >>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the >>> most from >>> the latest Intel processors and coprocessors. See abstracts and >>> register > >>> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk >>> ___ >>> WiX-users mailing list >>> WiX-users@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/wix-users >> >> -- >> October Webinars: Code for Performance >> Free Intel webinars can help you accelerate application performance. >> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the >> most from >> the latest Intel processors and coprocessors. See abstracts and >> register > >> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk >>
Re: [WiX-users] Upgrade confusion
How am I to detect that the bootstrapper has been invoked via an Update and thus should suppress the UI and auto-invoke the Install sequence? I dont see anything when comparing the 1.0.1 and 1.0.2 logs to indicate that an Update could be detected. There is one line at the top of the v1.0.2 log: i003: This bundle is being run by a related bundle as type 'Update'. But in DetectBegin the CustomBA.Model.Bootstrapper.Command.Action is "Install", when I would expect it to be "UpdateReplace". = Using Burn v3.8.1007.0. PID is *. Version Build is incremented on each build. = v1.0.1 Installed v1.0.1 Change launched from ARP, Update clicked, v1.0.2 downloaded and ExecutePackageComplete is success, v1.0.1 is exited automatically v1.0.2 Is auto opened, but instead of detecting it is an update and auto installing, it appears in the logs that the bootstrapper and MyApp are detected as Absent and it sits at the UI waiting for you to click Install. Thanks, -dirt On 2013-10-11 11:57, dirt wrote: > Thank you for the clarification. > > I have made progress and here is an updated scenario, I am not sure > why > the update is not auto-installing but instead waiting for me to click > Install (at step 2) > > = > Product ID = * > Product UpgradeCode = 029B...BD97 > Bootstrapper UpgradeCode = f031...56b3 > = > > 1) Install Bootstrapper v1.0.1 > > 2) Run Add/Remove Programs > Change, Launches v1.0.1 UI, Click Update > > Update downloads, runs, appears to install and close the original UI > (v1.0.1) and opens the new UI (v1.0.2) > > UI shows new version and shows as "Not Installed" with the Install > option enabled. > > = > This bundle is being run by a related bundle as type 'Update'. > DetectBegin: Not Installed > Detected package: MyApp, state: Absent > DetectComplete: DetectedAbsent > = > > ***a) Why does it not Auto Install? It is triggered by 'Update' yet > waits for me to click Install.*** > > 3) Click Install: Installs MyApp > > v1.0.2 is installed successfully > > v1.0.1 ui is opened again automatically (this time appears to be > hidden) > > 4) v1.0.2 UI shows as Complete. > > Add/Remove programs shows new v1.0.2 is installed. > = > > Thanks, > -dirt > > On 2013-10-10 19:08, Phill Hogland wrote: >> For MajorUpgrade behavior you must change both the Product ID and the >> version. The UpgradeCode should remain unchanged. Also the version >> of the >> MSI must change in the first three quad-dots. The version of the >> bundle can >> be changed in any part of the version string. >> >> http://wixtoolset.org/documentation/manual/v3/howtos/updates/major_upgrade.html >> >> I would set the Id="*" and increment the Build portion of the version >> string >> (Major.Minor.Build.Revision) to achieve what you are trying to do. >> >> >> >> -- >> View this message in context: >> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Upgrade-confusion-tp7589648p7589649.html >> Sent from the wix-users mailing list archive at Nabble.com. >> >> -- >> October Webinars: Code for Performance >> Free Intel webinars can help you accelerate application performance. >> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the >> most from >> the latest Intel processors and coprocessors. See abstracts and >> register > >> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk >> ___ >> WiX-users mailing list >> WiX-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wix-users > > -- > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the > most from > the latest Intel processors and coprocessors. See abstracts and > register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrade confusion
Thank you for the clarification. I have made progress and here is an updated scenario, I am not sure why the update is not auto-installing but instead waiting for me to click Install (at step 2) = Product ID = * Product UpgradeCode = 029B...BD97 Bootstrapper UpgradeCode = f031...56b3 = 1) Install Bootstrapper v1.0.1 2) Run Add/Remove Programs > Change, Launches v1.0.1 UI, Click Update Update downloads, runs, appears to install and close the original UI (v1.0.1) and opens the new UI (v1.0.2) UI shows new version and shows as "Not Installed" with the Install option enabled. = This bundle is being run by a related bundle as type 'Update'. DetectBegin: Not Installed Detected package: MyApp, state: Absent DetectComplete: DetectedAbsent = ***a) Why does it not Auto Install? It is triggered by 'Update' yet waits for me to click Install.*** 3) Click Install: Installs MyApp v1.0.2 is installed successfully v1.0.1 ui is opened again automatically (this time appears to be hidden) 4) v1.0.2 UI shows as Complete. Add/Remove programs shows new v1.0.2 is installed. = Thanks, -dirt On 2013-10-10 19:08, Phill Hogland wrote: > For MajorUpgrade behavior you must change both the Product ID and the > version. The UpgradeCode should remain unchanged. Also the version > of the > MSI must change in the first three quad-dots. The version of the > bundle can > be changed in any part of the version string. > > http://wixtoolset.org/documentation/manual/v3/howtos/updates/major_upgrade.html > > I would set the Id="*" and increment the Build portion of the version > string > (Major.Minor.Build.Revision) to achieve what you are trying to do. > > > > -- > View this message in context: > http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Upgrade-confusion-tp7589648p7589649.html > Sent from the wix-users mailing list archive at Nabble.com. > > -- > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the > most from > the latest Intel processors and coprocessors. See abstracts and > register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrade confusion
2013/10/10 dirt : > (Product ID and UpgradeCode are static, the Version (revision) is > incremented on each build.) That's the definition of a minor upgrade. If you want a major upgrade, you have to change product ID (ProductCode) too -- Nicolás -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrade confusion
For MajorUpgrade behavior you must change both the Product ID and the version. The UpgradeCode should remain unchanged. Also the version of the MSI must change in the first three quad-dots. The version of the bundle can be changed in any part of the version string. http://wixtoolset.org/documentation/manual/v3/howtos/updates/major_upgrade.html I would set the Id="*" and increment the Build portion of the version string (Major.Minor.Build.Revision) to achieve what you are trying to do. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Upgrade-confusion-tp7589648p7589649.html Sent from the wix-users mailing list archive at Nabble.com. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Upgrade confusion
I need some clarification on how to process Upgrades for the bootstrapper. I am trying to use major upgrades (for 'simplicity') for each bootstrapper build to replace the existing version installed. Here's an example of what I'm experiencing: (Product ID and UpgradeCode are static, the Version (revision) is incremented on each build.) = [ID = 82e6e1be-f56e-40ad-98a5-0c010dd77b3] [UpgradeCode = 029B62E4-4AFE-4D74-837D-D0E79622BD97] Run v1.0.0.1; detects as Not Installed. Click Install. Installs successfully. Run v1.0.0.2; detects as Installed. Close. Run v1.0.0.1; Click Update; appears to Download and Install v1.0.0.2 according to Logs completes successfully. v1.0.0.2 opens after old closes; detects as Installed. Add/Remove Programs still shows v1.0.0.1... Files are still v1.0.0.1 = It's at this point I don't understand why a) if v1 logs show update successfull then exit why v2 doesnt appear to be installed and b) why v2 is opened after v1 exits - shouldn't the install be seamless? Thank you, -dirt -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
