-
Notifications
You must be signed in to change notification settings - Fork 36
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
Patch seems to include more changes than was authored #6359
Comments
Because of the dread section-based patch filtering, the patch contains all the resources because the .wixpdb contains only the one section created by the linker. That's fixed with Rob's logical patch filtering. |
Not sure I follow. PatchAB2 is defined in https://github.com/wixtoolset/integration/blob/2f2e0624894cbcb63a3999086456f9044818385e/src/TestData/SlipstreamTests/PatchAB2/PatchAB2.wxs#L23. It is only supposed to bring in
The problem is that |
You're building the patches against the .wixpdbs from the .msis, right? Check the IR -- the symbols are flattened into a single section so the |
You can see the effects by opening the .msis in Orca and applying the patches. |
I guess what's tripping me up is that I can't believe that it was at the section level in v3, surely it was at the fragment level? I don't understand how this worked in v3. |
Section == fragment (and product, module, patchcreation). V4 is busted today in that it doesn't respect the original (authored) section. That's why Rob had #6375. |
So it's not broken because of how section-based filtering was designed. It's broken because v4 is not doing section-based filtering. |
It is doing section-based filtering, but with only one section to work with, it's not as selective as it might be... |
Bugs
If this issue is a bug:
The bundle has two MSI packages - PackageA and PackageB. Both packages have two registry values each. The bundle also has two MSP packages. Both patches target both products. Patch AB is supposed to have the changes for the first registry value, Patch AB2 is supposed to have the changes for the second registry value.
Burn is properly slipstreaming PatchAB into only PackageA and PatchAB2 into both packages. But, somehow the first registry value in PackageB is getting updated even though Burn didn't install any patches into that product that were supposed to patch it.
Burn log
The text was updated successfully, but these errors were encountered: