I find these discussions really hard without any requirements or design
docs (which was why I tried to start writing them down
<http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-documentation-td7594298.html>
).
I think Rob covered why it needs to be between UNINSTALL and CACHE. That
also makes it match BOOTSTRAPPER_REQUEST_STATE (where CACHE is between
ABSENT and PRESENT).
I don't understand the question about the command line. It'll be just like
if your BA had a /forceinstall switch (which maybe made it ignore install
conditions or something). Burn will not understand it and put it in the
command line that it gives to the BA.
I cloned your wix4 branch and built a test bundle to see how it worked (it
looked the same as wix3 and I wanted to be lazy and use the command line
switch):
Detected package: NetFx451Web, state: Present, cached: None
Detected package: UpdateReplace2MSI.msi, state: Absent, cached: None
Detected package: stuff1, state: Absent, cached: None
Planned package: NetFx451Web, state: Present, default requested: Present,
> ba requested: Present, execute: None, rollback: None, cache: No, uncache:
> No, dependency: None
> Planned package: UpdateReplace2MSI.msi, state: Absent, default requested:
> Present, ba requested: Present, execute: Install, rollback: None, cache:
> Yes, uncache: No, dependency: Register
> Planned package: stuff1, state: Absent, default requested: Absent, ba
> requested: Absent, execute: None, rollback: None, cache: No, uncache: No,
> dependency: None
> --- Begin plan dump ---
> Plan action: Cache
> per-machine: true
> keep registration by default: true
> estimated size: 32768
> Plan cache size: 32768
> Cache action[0]: CHECKPOINT id: 1
> Cache action[1]: PACKAGE_START id: UpdateReplace2MSI.msi, plan index
> for skip: 4, payloads to cache: 1, bytes to cache: 32768, skip until
> retried: No
> Cache action[2]: EXTRACT_CONTAINER id: WixAttachedContainer, working
> path:
> E:\testprojects\MBA4\UpdateReplace2Bundle\bin\Debug\UpdateReplace2Bundle.exe,
> skip until retried: No, skip until acquired by action: 2147483648
> extract package id: UpdateReplace2MSI.msi, payload id:
> UpdateReplace2MSI.msi, working path:
> C:\Users\First\AppData\Local\Temp\{9a719fca-3c38-4d7d-9461-82c730fc03de}\UpdateReplace2MSI.msi
> Cache action[3]: CACHE_PAYLOAD package id: UpdateReplace2MSI.msi,
> payload id: UpdateReplace2MSI.msi, working path:
> C:\Users\First\AppData\Local\Temp\{9a719fca-3c38-4d7d-9461-82c730fc03de}\UpdateReplace2MSI.msi,
> operation: move, skip until retried: No, retry action: 2
> Cache action[4]: PACKAGE_STOP id: UpdateReplace2MSI.msi, skip until
> retried: No
> Cache action[5]: SIGNAL_SYNCPOINT event handle: 0x3f0, skip until
> retried: No
> Plan execute package count: 0
> overall progress ticks: 1
> Execute action[0]: ROLLBACK_BOUNDARY id: WixDefaultBoundary, vital: yes
> Execute action[1]: CHECKPOINT id: 2
> Execute action[2]: PACKAGE_PROVIDER package id: UpdateReplace2MSI.msi,
> action: 1
> Execute action[3]: CHECKPOINT id: 3
> Execute action[4]: PACKAGE_DEPENDENCY package id:
> UpdateReplace2MSI.msi, bundle provider key:
> {9a719fca-3c38-4d7d-9461-82c730fc03de}, action: 1
> Execute action[5]: CHECKPOINT id: 4
> Execute action[6]: CHECKPOINT id: 5
> Rollback action[0]: ROLLBACK_BOUNDARY id: WixDefaultBoundary, vital: yes
> Rollback action[1]: PACKAGE_PROVIDER package id: UpdateReplace2MSI.msi,
> action: 2
> Rollback action[2]: CHECKPOINT id: 2
> Rollback action[3]: PACKAGE_DEPENDENCY package id:
> UpdateReplace2MSI.msi, bundle provider key:
> {9a719fca-3c38-4d7d-9461-82c730fc03de}, action: 2
> Rollback action[4]: CHECKPOINT id: 3
> Rollback action[5]: CHECKPOINT id: 4
> Rollback action[6]: CHECKPOINT id: 5
> Dependency action[0]: PLANNED_PROVIDER key:
> {9a719fca-3c38-4d7d-9461-82c730fc03de}, name: (null)
> --- End plan dump ---
> Plan complete, result: 0x0
> Apply begin
> Session begin, registration key:
> SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{9a719fca-3c38-4d7d-9461-82c730fc03de},
> options: 0x7, disable resume: No
> Caching bundle from:
> 'C:\Users\First\AppData\Local\Temp\{9a719fca-3c38-4d7d-9461-82c730fc03de}\.be\UpdateReplace2Bundle.exe'
> to: 'C:\ProgramData\Package
> Cache\{9a719fca-3c38-4d7d-9461-82c730fc03de}\UpdateReplace2Bundle.exe'
> Registering bundle dependency provider:
> {9a719fca-3c38-4d7d-9461-82c730fc03de}, version: 1.1.0.0
> Updating session, registration key:
> SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{9a719fca-3c38-4d7d-9461-82c730fc03de},
> resume: Active, restart initiated: No, disable resume: No
> Verified acquired payload: UpdateReplace2MSI.msi at path:
> C:\ProgramData\Package Cache\.unverified\UpdateReplace2MSI.msi, moving to:
> C:\ProgramData\Package
> Cache\{3A4998AD-EAE6-4C84-9C2E-576FFD18A9B7}v1.1.0.0\UpdateReplace2MSI.msi.
> Registering package dependency provider:
> {3A4998AD-EAE6-4C84-9C2E-576FFD18A9B7}, version: (null), package:
> UpdateReplace2MSI.msi
> Registering dependency: {9a719fca-3c38-4d7d-9461-82c730fc03de} on package
> provider: {3A4998AD-EAE6-4C84-9C2E-576FFD18A9B7}, package:
> UpdateReplace2MSI.msi
> Session end, registration key:
> SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{9a719fca-3c38-4d7d-9461-82c730fc03de},
> resume: ARP, restart: None, disable resume: No
> Updating session, registration key:
> SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{9a719fca-3c38-4d7d-9461-82c730fc03de},
> resume: ARP, restart initiated: No, disable resume: No
> Apply complete, result: 0x0, restart: None, ba requested restart: No
This is a Bundle that I reuse over and over again for testing, so the
authoring's pretty weird:
<Chain DisableSystemRestore="yes">
<PackageGroupRef Id="NetFx451Web"/>
<MsiPackage bal:PrereqPackage="yes"
SourceFile="$(var.UpdateReplace2MSI.TargetPath)" />
<ExePackage Id="stuff1"
SourceFile="C:\Users\First\Downloads\Wix37.exe" InstallCondition="0 = 1"
DetectCondition="WixBundleInstalled AND WixBundleAction = 5" />
</Chain>
I don't like that the Planned package message says it will install the MSI,
but it doesn't actually install it. I'm not sure it should be registering
any dependencies during the Cache operation. Before I ran this test I
didn't think it mattered that the BOOTSTRAPPER_ACTION_CACHE action wasn't
using the BOOTSTRAPPER_REQUEST_STATE_CACHE state, but now I think it has to
in order for the execute action to be None. Which means that your pull
request won't actually work without my pull request. Sorry.
I notice that there are two differences in the refactor of plan.cpp between
our pull requests. One is that you disable the rollback actions during the
CACHE operation, I don't think you can do that - the packages will be left
on the machine without any way to delete them (except manually). Or am I
missing something?
The other one's a toss up. I chose to look at the special case of
BURN_CACHE_TYPE_ALWAYS in ProcessPackage, and you did it in
PlanDependencyActions. Naturally I'm biased towards mine...
On Wed, Mar 4, 2015 at 10:49 AM, Rob Mensching <r...@firegiant.com> wrote:
> Why? Won’t “additional command-line arguments” be appended so that
> whatever was called “CACHE” on the command line (/cache or /store or
> /whateverBAchooses) would get put back on there? Or am I not remembering
> the code correctly?
>
>
>
> _______________________________________________________________
>
> FireGiant | Dedicated support for the WiX toolset |
> http://www.firegiant.com/
>
>
>
> *From:* Heath Stewart [mailto:hea...@outlook.com]
> *Sent:* Tuesday, March 3, 2015 10:53 PM
> *To:* WiX toolset developer mailing list
> *Subject:* Re: [WiX-devs] BOOTSTRAPPER_ACTION_CACHE
>
>
>
> Reviewing other changes I may need to make apart from removing command
> line support, CoreRecreateCommandLine does pass /cache and seems it would
> need to for the original scenario. But since command line args not
> understood by Burn are passed through, is this okay? Only a parent BA could
> do this, but then again - nothing now sets BURN_COMMAND::action to
> BOOTSTRAPPER_ACTION_CACHE. Do we just leave it up to the BAs to know when
> to set package stats to CACHE?
>
>
>
> - Heath from my Surface Pro 3
>
>
>
> *From:* Heath Stewart <hea...@outlook.com>
> *Sent:* Tuesday, March 3, 2015 9:51 PM
> *To:* WiX toolset developer mailing list <wix-devs@lists.sourceforge.net>
>
>
>
> Sean and Rob, during triage you mentioned that you didn't think CACHE
> should be before UNINSTALL, but it was placed between LAYOUT and UNINSTALL
> (synonymous with Absent often times), which logically makes sense. If
> LAYOUT ~= source layout and ABSENT ~= not installed, then CACHE ~= in
> between source and install - exactly what the cache is for.
>
>
>
> So do you really think this needs to change? At the very least, it should
> be close to LAYOUT which is also before UNINSTALL.
>
>
>
> - Heath from my Surface Pro 3
>
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> WiX-devs mailing list
> WiX-devs@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-devs
>
>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-devs
