Add burn support for only caching packages #213
Conversation
|
Let's talk about this at Tuesday's meeting. We'd talked about making this something the BA could tell the engine to do rather than making it an all-engine job. |
|
My $0.02 in case I can't make triage: take this into wix3 as-is. Any changes to the BA will likely require an interface change which I know @robmen is rethinking for wix4. |
Conflicts: History.md
|
If this looks good, I'll make the same changes for the wix4 branch. @rseanhall , please have a look as well since I know you have a related PR. |
| @@ -452,6 +454,9 @@ extern "C" HRESULT ApplyCache( | |||
| hr = UserExperienceInterpretExecuteResult(pUX, FALSE, MB_OKCANCEL, nResult); | |||
| ExitOnRootFailure(hr, "UX aborted cache."); | |||
|
|
|||
| // When in cache mode, we want to download in the background (if the download mechanism supports it). | |||
| BOOL fPreferBackgroundDownload = (BOOTSTRAPPER_ACTION_CACHE == pPlan->action); | |||
There was a problem hiding this comment.
This seems pretty magical. Seems like BITS needs more callbacks (or something) to handle it's priority. Not great answer here but this may be the best can do in v3.x. @barnson, thoughts?
There was a problem hiding this comment.
I worry about using the "idle" levels for something with UI. But not worth an interface change, for sure.
There was a problem hiding this comment.
Background downloads removed. Originally it was to support async execution anyway, so probably didn't fit well with this change anyway.
|
Since you took @rseanhall's implementation, is there any point in this PR now? I don't understand what he was getting at since he was claiming there was a bug in something that Burn didn't seem to support (which was waiting on the original PR that included async). |
Conflicts: History.md src/burn/engine/plan.cpp
Resolves issue #4432 by adding a BOOTSTRAPPER_ACTION_CACHE mode that BAs can set (i.e. Burn does not directly support setting via command line) and will plan to cache all package types by default. WixStdBA was updated to support this mode if opted in via a new @SupportCacheOnly attribute.
| @@ -1920,6 +1927,10 @@ static HRESULT GetActionDefaultRequestState( | |||
|
|
|||
| switch (action) | |||
| { | |||
| case BOOTSTRAPPER_ACTION_CACHE: | |||
| *pRequestState = BOOTSTRAPPER_REQUEST_STATE_CACHE; | |||
There was a problem hiding this comment.
This needs to be like MODIFY, it depends on the current state of the package. If the package is PRESENT and the default action is CACHE, then the package would get uninstalled.
There was a problem hiding this comment.
Good point. I'll need to go back and check our internal code since this has changed a bit to see if there's a problem there. Looking through the current and request states, seems it's just (current->requested): present->present, cache->none (though I can't find anything in the code not commented out that sets BOOTSTRAPPER_PACKAGE_STATE_CACHE), and *->cache.
Conflicts: History.md src/ext/BalExtension/wixext/BalCompiler.cs src/ext/BalExtension/wixext/Xsd/bal.xsd src/ext/BalExtension/wixext/data/tables.xml src/ext/BalExtension/wixstdba/WixStandardBootstrapperApplication.cpp
|
This looks like it's ready to merge (except for the History.md changes that are easily fixed). I'll have to test out the failure scenario and see what get left behind in the cache. |
Add burn support for only caching packages
Rebased and squashed on top of the current
developHEAD. This does not include the async install as there was some debate about it and we do not think we'll need it going forward anyway.