Subject: Re: [WiX-devs] BOOTSTRAPPER_ACTION_CACHE
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 co
:
> 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?
>
>
>
> ___
://www.firegiant.com/
From: Heath Stewart [mailto:hea...@outlook.com]
Sent: Tuesday, March 3, 2015 9:45 PM
To: WiX toolset developer mailing list
Subject: [WiX-devs] BOOTSTRAPPER_ACTION_CACHE
Sean and Rob, during triage you mentioned that you didn't think CACHE should be
before UNINSTALL, b
?
___
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
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,
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 sou
