Thanks.It'd be best if all this was captured in a bug to be investigated
On Wed, Sep 12, 2012 at 4:43 PM, Tim Comport wrote:
> Here are the logs from the exact same test but with the SceduleReboot
> element
> commented out of Package A. This upgrade is successful.
>
> The main difference I see i
Here are the logs from the exact same test but with the SceduleReboot element
commented out of Package A. This upgrade is successful.
The main difference I see is the dependents check i.e. dependents are
actually found during this successful upgrade (and so A and B are correctly
left alone). Not
I forgot to point out the scenario for the logs:
- Bundle with 3 packages A, B, C
- Package A Schedules a reboot
- Package A and B are unchanged from initial 1.0.0.0 Bundle
- Package C has been changed from 1.0.0.0 to 1.0.1.0 (upgrade)
- Bundle version has been changed from 1.0.0.0 to 1.0.1.0 (Prod
Ok, did some more testing today:
1. This occurs with wixstdba or my custom ba
2. Upgrade fails (uninstalls all unchanged packages) when first package in
bundle is unchanged and schedules a reboot
3. Upgrade succeeds if first package in bundle is unchanged but does NOT
schedule a reboot
4. Upgrade
Ahh, I think this may be the wixstdba trying to avoid a
restart-infinite-loop. After a restart the wixstdba tells the engine to
skip packages that were installed before the restart so that they do not
inadvertently cause a restart again. That's my current guess anyway.
The original logs you poste
I noticed that the bug suggested to be related had been closed, so I tried
this again with WiX 3.6.3303.1. The problem is still there.
Just to re-iterate:
1. Bundle major upgrade (where 1 or more packages are unchanged, and 1 or
more are major upgrades)
2. If any of the packages schedule a reboot:
However, in this case installation is fine.
Only upgrades are affected, and even upgrades complete (seemingly) successfully.
There are no other burn processes spawned as suggested in the linked issue (ID:
3538260).
In the case I have described it seems as if 'ScheduleReboot' simply causes burn
Sounds like it could be related to:
http://sourceforge.net/tracker/?func=detail&aid=3538260&group_id=105970&atid=642714
On Wed, Jul 11, 2012 at 10:38 PM, Tim Comport wrote:
>
> Further investigation (trial and error) reveals that this has something to
> do with 'ScheduleReboot'.
> It seems that i
Further investigation (trial and error) reveals that this has something to do
with 'ScheduleReboot'.
It seems that if any of the packages schedule a reboot using:
it causes the issue described.
However, if no reboot is scheduled by any package (I manually removed it for
testing) then up
I am using WiX 3.6.3102, and I'm having an issue when upgrading my burn
bootstrapper.
For testing upgrade scenario's I have built two bundle's:
Bundle B1 v1.0.1.0
- Package P1 vX.X.X.X
- Package P2 vY.Y.Y.Y
- Package P3 v1.0.1.0
Bundle B2 v1.0.2.0
- Package P1 vX.X.X.X
- Package P2 vY.Y.Y.Y
-
10 matches
Mail list logo
