If B3 is a related bundle to B1, B3 would be repaired or uninstalled when B1 is repaired or uninstalled. This should be sufficient. For B1 to know about P1' means we can't know all state: properties passed in when B3 was installed, feature selection, and perhaps more. But if B3 is a patch or addon related bundle with B1, these scenarios work out.

Because the same provider key is a declaration of compatibility, the decided implementation is to attempt to detect any other product on the system that uses the same provider key. Currently, this is expected to be stored in the default registry value but we will also check the registry key since, by default, that is also the ProductCode (though, that would have to change). The code should be factored to allow for additional detection, though it's important to note that any other ways of detecting compatible products must be backward compatible (i.e. not depend on that information but fall back to previous behavior).

As long as the MSI uses a fixed provider key - which it would have to in order to claim compatibility - the current Burn bundle could enumerate the dependents of that provider key, filter for all the bundles (except ourselves), then run an install operation on those bundles to restore the correct state (similar to sticky patching, but during bundle uninstall).

We'll consider this for 3.7 but don't believe it is required now. The current behavior also yields the benefit of less complication while a repair of existing bundles will put everything back in place.

Originally changed by barnson
Release changed from v3.8 to v3.x

Does anyone understand this bug? I have no idea what's supposed to fail.

🤷 @heaths, do you remember?

I think this was a case where installing B1 when B3 or B4 was already installed generates the wrong plan for P1 because P1' or P1'' is already installed. But I don't remember ever using SourceForge for bugs. Did this come from Product Studio or CodePlex? I'm wondering if there were logs attached originally. I imagine CodePlex issues are completely gone, but I could see if I could find a read-only copy of the Product Studio database. Or maybe it's worth adding a test and trying it. Presumably, since I said P1'' upgrades P1' upgrades P1 they should all have the same UpgradeCode (typically; obviously a combination of different UCs and Upgrade table entries would work but I doubt that's the practical scenario here).

This problem stems from the discussion @robmen and I had way back when I first started writing up the package ref counting design, that we didn't want to automatically add provider keys for MSIs because UpgradeCode wasn't a required property (and one reason we did require it for bundles - for possible eventual related bundles). This, the resolution here - reading the other comments I made - may have been the suggestion that, either automatically or through validation - we "encourage" a fixed provider key that we can enumerate and discover related packages installed by newer bundles even though there's no possible way older bundles could've known about them. We actually ended up doing something similar to that in the VS Setup engine I designed for VS2017+. It implements the original package ref-counting spec and improves on a few behaviors to support newer packages already installed like this issue might be trying to say.

Did this come from Product Studio or CodePlex?

It migrated from Rob's custom bug database, which had migrated bugs from SourceForge. As far as I know, issues were never on CodePlex.

Or maybe it's worth adding a test and trying it.

There will be no issues if only major upgrades are happening, and I have to assume that based on the title. I also have to assume that none of the bundles are related to each other. Thus my comment, I have no idea what's supposed to fail.

I also have to assume that none of the bundles are related to each other.

Ah, yes. You're probably right since I never mentioned any relationship between them like I did P1. But that would seem to add weight to what I was thinking this might be and what we do in the VS Setup engine: the dependency manager, if it has a provider key registered (we harvest them from packages that have them if not explicit authored at build time), will query the package's installed state based on that provider key and, if found, enumerate providers. If a newer provider version is installed, the package will not actually be installed but an entry for that bundle e.g., B1, will be added as another provider of P1. In fact, that's probably already happening with Burn now, IIRC. But what might not be handled now (or perhaps it was added later and this issue just never cleaned up / forgotten about) was that B1 would have no idea how to uninstall P1'' or P1' because it doesn't have the info. That would better explain my suggestions of information to use like an MSI's ProductCode - which should already be available in the package info being ref-counted - and assume any features/properties (if defined) will still work. That last part we also do in the VS Setup engine to attempt to clean up better and it's been largely successful. After all, at least for an MSI, you uninstall with REMOVE=ALL so any feature incongruity wouldn't matter, and the others are removed by path. The only likely issue would be for EXEs, but I would imagine that in the vast majority of cases an uninstall command would be fairly universal and, at the very least, the bundle e.g., B1, tried. If the package fails to uninstall, a non-fatal warning should be logged already.

So this is Uninstall compatible orphaned MSI packages from wixtoolset/wix3#15. That implementation was not restrictive enough on the elevated side so I still need to reimplement that in v4.

Good memory! I forgot about that one. Yes, that does appear to be the solution for the assumed problem herein.

The interaction between that feature and #6297 was extremely confusing, so I'm not likely to forget it any time soon.

This issue can probably be resolved.