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
Comments
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.
|
|
The Wix 3.9 bundle is a patch bundle for the WiX 3.6 bundle (<RelatedBundle Id="" Action="Patch"/>).
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.
|
I can't reproduce the problem with some dummy bundles.
Can you post logs from all three installs, including the nested run of the v3.6 bundle?
|
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 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 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
|
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.
|
Much appreciated for investigating this. I'll take your advice and check for the Embedded display type only.
|
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
where {af1b389f-121d-41c0-8d6e-d9e5ecf4f627} is the WiX 3.6 bundle.
When the WiX 3.6 bundle is invoked the log states
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.
The text was updated successfully, but these errors were encountered: