Plan MSI transactions #28
Conversation
There was a problem hiding this comment.
I won't be able to take this until it's implemented in the Burn repo. When implementing this there, make sure that the BA's decision is only recorded in the plan. This is important because the BA can do Plan multiple times. For each new plan, the authored value needs to be the default.
| /// When false on entry, then an MSI tranaction is either not authored or not supported on the target machine. In this case, setting the value to true has no effect. | ||
| /// When true on entry, setting to false will disable the transaction and packages will be installed without a wrapping MSI transaction. |
There was a problem hiding this comment.
I don't think the engine should send OnPlanMsiTransaction at all unless it was authored as an MSI transaction. This probably made more sense in your v3 fork where it could have been running on a machine that didn't support MSI transactions, but it doesn't make sense here. Following from that, the signature should just be wzTransactionId as input parameter and fTransaction as in/out. There's no reason for fTransaction and pfTransaction.
| @@ -189,6 +189,15 @@ static HRESULT BalBaseBAProcOnPlanPatchTarget( | |||
| return pBA->OnPlanPatchTarget(pArgs->wzPackageId, pArgs->wzProductCode, pArgs->recommendedState, &pResults->requestedState, &pResults->fCancel); | |||
| } | |||
|
|
|||
| static HRESULT BalBaseBAProcOnPlanMsiTransaction( | |||
There was a problem hiding this comment.
You will need to call this from a new case statement below.
No description provided.