Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Burn command line: Backward compatibility broken #4490

Closed
wixbot opened this issue Aug 7, 2014 · 7 comments
Closed

Burn command line: Backward compatibility broken #4490

wixbot opened this issue Aug 7, 2014 · 7 comments
Assignees
Milestone

Comments

@wixbot
Copy link

wixbot commented Aug 7, 2014

Repairing a WiX 3.6 bundle as a dependent WiX 3.9 bundle fails, because of an unknown command line switch.

I have installed a WiX 3.6 bundle and a patch bundle for it.
When upgrading the patch bundle the log states

[05C0:0D84][2014-08-07T13:05:56]i001: Burn v3.9.721.0, Windows v6.1 (Build 7601: Service Pack 1), path: C:\Users\DSedlmay\Desktop\Debug\Setup.exe, cmdline: ''
...
[05C0:0D84][2014-08-07T13:06:01]i207: Planned related bundle: {af1b389f-121d-41c0-8d6e-d9e5ecf4f627}, type: Dependent, default requested: Repair, ba requested: Repair, execute: Repair, rollback: None, dependency: None
[05C0:0D84][2014-08-07T13:06:01]i207: Planned related bundle: {20e1a153-1c37-47ad-bb41-4216364126da}, type: Upgrade, default requested: None, ba requested: None, execute: None, rollback: None, dependency: None

where {af1b389f-121d-41c0-8d6e-d9e5ecf4f627} is the WiX 3.6 bundle.

When the WiX 3.6 bundle is invoked the log states

[0FF0:052C][2014-08-07T13:08:08]: Burn v3.6.3303.0, Windows v6.1 (Build 7601: Service Pack 1), path: C:\ProgramData\Package Cache\{af1b389f-121d-41c0-8d6e-d9e5ecf4f627}\Setup.exe, cmdline: '-repair -quiet -burn.ancestors={e8ca501b-3cec-4d5f-b51f-0d3f8c2519ea} -burn.embedded BurnPipe.{4BD0F760-DFEE-4FA7-B256-2DF8FC58027A} {A5825A92-527B-48FA-A7E1-E7BCC6658D60} 1904 -burn.unelevated BurnPipe.{6CAB9D6C-3C84-4252-B319-3F98DC2B9D33} {285DF9EC-B8AA-4EC7-936F-CC8C81715D13} 3556'
[0FF0:052C][2014-08-07T13:08:08]: Unknown burn internal command-line switch encountered: 'burn.ancestors={e8ca501b-3cec-4d5f-b51f-0d3f8c2519ea}'.

Somehow this seem to affect Microsoft.Tools.WindowsInstallerXml.Bootstrapper.Command.Relation and causes our managed bootstrapper application to fail:
It blocks installation, because it assumes that another unrelated installation is already running.

Originally opened by dieter.sedlmayer

@wixbot
Copy link
Author

wixbot commented Aug 7, 2014

Do you have RelatedBundle entries for the 3.6 bundle? If so, what kind? How is your BA deciding to block? Can you build the 3.9 bundle with 3.6 (or 3.7) and report the differences in the command line? Extra switches are OK but there might be switches that were dropped.

Originally posted by barnson

@wixbot
Copy link
Author

wixbot commented Aug 7, 2014

AssignedTo set to bobarnson

@wixbot
Copy link
Author

wixbot commented Aug 8, 2014

The Wix 3.9 bundle is a patch bundle for the WiX 3.6 bundle (<RelatedBundle Id="" Action="Patch"/>).
The scenario is as follows:

  • I installed the WiX 3.6 bundle

  • I installed the WiX 3.9 patch bundle

  • I installed the WiX 3.9 patch bundle again, but after a rebuild (so the Id changed, but the version stays the same)

    I haven't tried yet what happens when I also change the version before applying the patch bundle again, but I expect it to upgrade the existing patch bundle, not touching the WiX 3.6 bundle on install and to be removed when uninstalling the Wix 3.6 bundle. Actually I am not understanding why the engine request a repair though.

My BA decides on the state of a global mutex and the Command.Relation state when to block. If the mutex is set, but the Relation is None it assumes that another installer is already running and blocks.

WiX 3.7 is not an option for me, because of another issue that was fixed in 3.9. I'll check the behavior when using 3.6 though.

Originally posted by dieter.sedlmayer

@wixbot
Copy link
Author

wixbot commented Aug 8, 2014

I can't reproduce the problem with some dummy bundles.

[1468:1A10][2014-08-08T17:58:16]i207: Planned related bundle: {3b6920a3-e810-45f2-8616-817a9f8c3b49}, type: Dependent, default requested: None, ba requested: None, execute: None, rollback: None, dependency: None

Can you post logs from all three installs, including the nested run of the v3.6 bundle?

Originally posted by barnson

@wixbot
Copy link
Author

wixbot commented Aug 12, 2014

Hello Bob,

I can reproduce the problem using two bundles only. A base product created with WiX 3.6 and a patch bundle created with WiX 3.9. In contrary to my previous description the problem arises when uninstalling the patch bundle.

Uninstalling a similar patch bundle created with WiX 3.6 results in:

[0160:0E4C][2014-08-12T10:54:57]: Detected related bundle: {af1b389f-121d-41c0-8d6e-d9e5ecf4f627}, type: Dependent, scope: PerMachine, version: 7.2.1.5537, operation: None
...
[0160:0E4C][2014-08-12T10:55:01]: Plan 11 packages, action: Uninstall
[0160:0E4C][2014-08-12T10:55:01]: Planned related bundle: {af1b389f-121d-41c0-8d6e-d9e5ecf4f627}, type: Dependent, default requested: None, ba requested: None, execute: None, rollback: None, dependency: None
[0160:0E4C][2014-08-12T10:55:01]: Planned package: exePackage.Thermo.Chromeleon.SystemConfiguration.Patch, state: Absent, default requested: None, ba requested: None, execute: None, rollback: None, cache: No, uncache: Yes, dependency: None
[0160:0E4C][2014-08-12T10:55:01]: Planned package: msiPackage.Thermo.Chromeleon.SII.AccessList, state: Present, default requested: Absent, ba requested: Absent, execute: Uninstall, rollback: Install, cache: No, uncache: Yes, dependency: Unregister
[0160:0E4C][2014-08-12T10:55:01]: Planned package: mspPackage.Thermo.Chromeleon.CoreComponents, state: Present, default requested: Absent, ba requested: Absent, execute: Uninstall, rollback: Install, cache: No, uncache: Yes, dependency: None
[0160:0E4C][2014-08-12T10:55:01]: Planned package: exePackage.Thermo.Chromeleon.SystemConfiguration.Patch.Prepare, state: Present, default requested: Absent, ba requested: Absent, execute: Uninstall, rollback: Install, cache: No, uncache: Yes, dependency: None
[0160:0E4C][2014-08-12T10:55:01]: Planned package: exePackage.Thermo.Chromeleon.USB.Driver.Package.x86.Silent, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[0160:0E4C][2014-08-12T10:55:01]: Planned package: exePackage.Thermo.Chromeleon.USB.Driver.Package.x86.Visible, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[0160:0E4C][2014-08-12T10:55:01]: Planned package: exePackage.Thermo.Chromeleon.USB.Driver.Package.x64.Silent, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[0160:0E4C][2014-08-12T10:55:01]: Planned package: exePackage.Thermo.Chromeleon.USB.Driver.Package.x64.Visible, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: Yes, dependency: None
[0160:0E4C][2014-08-12T10:55:01]: Planned package: msuPackage.Microsoft.Windows.Installer.4.5.Vista.KB958655.v2.x86, state: Absent, default requested: None, ba requested: None, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[0160:0E4C][2014-08-12T10:55:01]: Planned package: msuPackage.Microsoft.Windows.Installer.4.5.Vista.KB958655.v2.x64, state: Present, default requested: None, ba requested: None, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[0160:0E4C][2014-08-12T10:55:01]: Planned package: exePackage.Microsoft.Net.4.0.Full.Core, state: Present, default requested: None, ba requested: None, execute: None, rollback: None, cache: No, uncache: No, dependency: None

Uninstalling the WiX 3.9 patch bundle results in:

[1288:0194][2014-08-12T11:20:29]i102: Detected related bundle: {af1b389f-121d-41c0-8d6e-d9e5ecf4f627}, type: Dependent, scope: PerMachine, version: 7.2.1.5537, operation: None
...
[1288:0194][2014-08-12T11:23:07]i200: Plan begin, 5 packages, action: Uninstall
[1288:0194][2014-08-12T11:23:07]i207: Planned related bundle: {af1b389f-121d-41c0-8d6e-d9e5ecf4f627}, type: Dependent, default requested: Repair, ba requested: Repair, execute: Repair, rollback: None, dependency: None
[1288:0194][2014-08-12T11:23:07]i201: Planned package: exePackage.Thermo.Chromeleon.SystemConfiguration.Patch, state: Absent, default requested: None, ba requested: None, execute: None, rollback: None, cache: No, uncache: Yes, dependency: None
[1288:0194][2014-08-12T11:23:07]i201: Planned package: exePackage.Thermo.Chromeleon.SystemConfiguration.Patch.Before, state: Present, default requested: Absent, ba requested: Absent, execute: Uninstall, rollback: Install, cache: Yes, uncache: Yes, dependency: None
[1288:0194][2014-08-12T11:23:07]i201: Planned package: msuPackage.Microsoft.Windows.Installer.4.5.Vista.KB958655.v2.x86, state: Absent, default requested: None, ba requested: None, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[1288:0194][2014-08-12T11:23:07]i201: Planned package: msuPackage.Microsoft.Windows.Installer.4.5.Vista.KB958655.v2.x64, state: Present, default requested: None, ba requested: None, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[1288:0194][2014-08-12T11:23:07]i201: Planned package: exePackage.Microsoft.Net.4.0.Full.Core, state: Present, default requested: None, ba requested: None, execute: None, rollback: None, cache: No, uncache: No, dependency: None
...
[0DF0:086C][2014-08-12T11:23:48]i301: Applying execute package: {af1b389f-121d-41c0-8d6e-d9e5ecf4f627}, action: Repair, path: C:\ProgramData\Package Cache{af1b389f-121d-41c0-8d6e-d9e5ecf4f627}\Setup.exe, arguments: '"C:\ProgramData\Package Cache{af1b389f-121d-41c0-8d6e-d9e5ecf4f627}\Setup.exe" -repair -quiet -burn.ancestors={adadd2f2-4482-4f3b-8feb-4c7d5a59c015}'

such the Wix 3.9 patch bundle is suddenly requesting a repair of the base bundle. But when the base bundle is invoked its relation is None
I do not bother too much about the repair, although annoying, but about the relation. None seems to be wrong, especially when the dependent package needs to know the reason of invocation
As an alternative: Is the Embedded display type exclusively used for calling related bundles
only?

Originally posted by dieter.sedlmayer

@wixbot
Copy link
Author

wixbot commented Aug 14, 2014

Thanks for all the detail, it's helped! The behavior change from v3.8 is that when you uninstall a patch bundle, it triggers a repair of its parent. That was an intentional change to fix a bug (when a patch bundle included major upgrade packages, uninstalling the bundle removed the packages and didn't put the old ones back). However, there isn't currently a relationship type to indicate that a child bundle is invoking its parent; all the existing types point from parent to child. We'll add that in a future release but it won't solve your existing problem in v3.6. The best advice is that when the display is set to embedded, your BA shouldn't block. It's safe to assume there's a relationship of some type when display is embedded.

Resolution set to behaviorchange
Status changed from Open to Resolved

@wixbot
Copy link
Author

wixbot commented Aug 18, 2014

Much appreciated for investigating this. I'll take your advice and check for the Embedded display type only.

Originally posted by dieter.sedlmayer

@wixbot wixbot added this to the v3.9 milestone Dec 20, 2015
@wixbot wixbot closed this as completed Dec 20, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants