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
Major upgrades with unrelated bundles fail #3190
Comments
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. |
|
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. |
It migrated from Rob's custom bug database, which had migrated bugs from SourceForge. As far as I know, issues were never on CodePlex.
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, |
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 |
So this is |
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. |
We need to fix and test the following scenario:
B1 = { P1 }
B2 = { P1, P2 }
B3 = { P1' }
B4 = { P1'' }
P1'' upgrades P1' upgrades P1.
Older bundles know nothing of newer versions of P1. Could solve by authoring a common provider key, and during Detect() lookup the unique default value (MSI: ProductCode; MSP: patch code; MSU: component ID; EXE: nothing) if the package was not detected as coded already.
The text was updated successfully, but these errors were encountered: