https://bugs.winehq.org/show_bug.cgi?id=41269
Bug ID: 41269 Summary: MSI uninstaller does not clean up Registry's UpgradeCode, ProductCode Product: Wine Version: 1.9.17 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: critical Priority: P2 Component: msi Assignee: wine-bugs@winehq.org Reporter: reinhold.hoffmann@hotmail.com Distribution: ---
Created attachment 55569 --> https://bugs.winehq.org/attachment.cgi?id=55569 What needs to be deleted in the Registry when de-installing
When uninstalling an installed Wine app the uninstaller de-installs the app accurately but it does not clean up the UgradeCode and ProductCode in the Registry. In an subsequent installation when the same app (same UpgradeCode, different ProductCode, higher version number) is installed, the MSI option "RemoveExistingProducts" fails. "RemoveExistingProducts" should automatically de-install a former version before the new version is installed. As a consequence always the former version needs to be manually de-install BEFORE the new version otherwise the next installation fails.
In addition the Windows call "MsiEnumRelatedProducts" finds a product which does not exist anymore. De-installing with "MsiConfigureProduct (parameter=ProductCode, INSTALLLEVEL_DEFAULT, INSTALLSTATE_ABSENT)" does not work either.
Because the MSI uninstaller leaves all ProductCodes of former installations in place forever, the Registry get screwed and is not in sync to what really is installed.
This is a big issue for almost every our customer when installing updates or upgrade. Always, the former installation has to be manually de-installed because "RemoveExistingProducts" always fails. We have detected this issue in a deep dive and see this bug to be the biggest issue for our customers for a broader use of our software on Wine. Therefore set this bug to be critical.
Please find attached what needs to be deleted in the Registry when the uninstaller de-installs a software.
The bug happens for Ubuntu, openSuSE, Mac OS X
Reinhold
https://bugs.winehq.org/show_bug.cgi?id=41269
--- Comment #1 from Rosanne DiMesio dimesio@earthlink.net --- *** Bug 41270 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=41269
Rosanne DiMesio dimesio@earthlink.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|critical |normal
--- Comment #2 from Rosanne DiMesio dimesio@earthlink.net --- Not critical.
https://bugs.winehq.org/show_bug.cgi?id=41269
--- Comment #3 from Reinhold reinhold.hoffmann@hotmail.com --- Rosanne, thanks for identify the duplicate. The bug server access was very slow and broke. I wasn't sure that the report made it.
With regards whether the bug is "critical" or "not", we can debate. We spent some considerable time finding out the issue. I just want to emphasize and want to make clear that EVERY WINDOWS APPLICATION ON WINE is impacted by this bug.
A final solution also need to handle the situation that existing screwed Registry entries need to be cleaned up.
Thanks for support.
https://bugs.winehq.org/show_bug.cgi?id=41269
--- Comment #4 from Hans Leidekker hans@meelstraat.net --- Looks like there are two issues here: the upgrade code is not removed and the product key is not deleted. If I uninstall the wine-mono package its upgrade code is still there but its product key is properly deleted.
Can you point to an installer that shows the second problem?
https://bugs.winehq.org/show_bug.cgi?id=41269
Reinhold reinhold.hoffmann@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|1.9.17 |1.9.18
--- Comment #5 from Reinhold reinhold.hoffmann@hotmail.com --- Thanks. The issue can be reproduced by
http://www.notation.com/download/Inst_NS_Composer_3_English_Trial.msi
When uninstalling with "wine uninstaller" the UpgradeCode and ProductCode stay. This msi has no special uninstall path (which is not required).
https://bugs.winehq.org/show_bug.cgi?id=41269
--- Comment #6 from Hans Leidekker hans@meelstraat.net --- Created attachment 55580 --> https://bugs.winehq.org/attachment.cgi?id=55580 patch
Can you try this patch?
https://bugs.winehq.org/show_bug.cgi?id=41269
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |Installer, patch
--- Comment #7 from Austin English austinenglish@gmail.com --- (In reply to Reinhold from comment #3)
With regards whether the bug is "critical" or "not", we can debate. We spent some considerable time finding out the issue. I just want to emphasize and want to make clear that EVERY WINDOWS APPLICATION ON WINE is impacted by this bug.
Not every application uses an MSI installer.
https://bugs.winehq.org/show_bug.cgi?id=41269
--- Comment #8 from Reinhold reinhold.hoffmann@hotmail.com --- (In reply to Hans Leidekker from comment #6)
Created attachment 55580 [details] patch
Can you try this patch?
Hans, Thanks for immediately take care and providing a patch.
But unfortunately I cannot test the patch because I do not have a Wine development environment available and running. I only use public distributions on the different operating systems and have not done any patching so far. Sorry. Is there any other thing I can do?
https://bugs.winehq.org/show_bug.cgi?id=41269
--- Comment #9 from Reinhold reinhold.hoffmann@hotmail.com --- (In reply to Austin English from comment #7)
(In reply to Reinhold from comment #3)
With regards whether the bug is "critical" or "not", we can debate. We spent some considerable time finding out the issue. I just want to emphasize and want to make clear that EVERY WINDOWS APPLICATION ON WINE is impacted by this bug.
Not every application uses an MSI installer.
Thanks. OK agreed (not every), but many Windows apps use the MSI installer. Thanks to the Wine team for taking immediate action. Great job.
https://bugs.winehq.org/show_bug.cgi?id=41269
--- Comment #10 from Bruno Jesus 00cpxxx@gmail.com --- (In reply to Hans Leidekker from comment #6)
Created attachment 55580 [details] patch
Can you try this patch?
Tried by installing/removing/reinstalling the application in 2 different prefixes with and without the patch.
Unfortunately in both I'm able to reinstall the application. I believe we need a second program with different version number to test (?).
What is the valid test procedure, Reinhold?
https://bugs.winehq.org/show_bug.cgi?id=41269
--- Comment #11 from Reinhold reinhold.hoffmann@hotmail.com --- Thanks. Of course. I have created such a scenario and have tested it thoroughly on Windows 7 and on Wine. Please find attached the scenario in details (file: Wine_bug_41296_Test_Scenario.txt). Hope this helps. Please let me know if you need more information.
https://bugs.winehq.org/show_bug.cgi?id=41269
--- Comment #12 from Reinhold reinhold.hoffmann@hotmail.com --- Created attachment 55585 --> https://bugs.winehq.org/attachment.cgi?id=55585 Wine_bug_41296_Test_Scenario
https://bugs.winehq.org/show_bug.cgi?id=41269
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever confirmed|0 |1
--- Comment #13 from Bruno Jesus 00cpxxx@gmail.com --- (In reply to Reinhold from comment #12)
Created attachment 55585 [details] Wine_bug_41296_Test_Scenario
Thank you very much. I can confirm that the attempt to update the program brings the Repair/Remove screen and that after the patch this problem is still present.
I'm going to attach 2 log files with of patched/unpatched program update attempt stopped when the wrong repair/remove screen is reached. But I diff'ed then and they seem identical to me. I then added extra debug to the new added functions in the patch and they don't seem to be called.
Am I doing something wrong?
https://bugs.winehq.org/show_bug.cgi?id=41269
--- Comment #14 from Bruno Jesus 00cpxxx@gmail.com --- Created attachment 55588 --> https://bugs.winehq.org/attachment.cgi?id=55588 unpatched upgrade attempt +msi
https://bugs.winehq.org/show_bug.cgi?id=41269
--- Comment #15 from Bruno Jesus 00cpxxx@gmail.com --- Created attachment 55589 --> https://bugs.winehq.org/attachment.cgi?id=55589 patched upgrade attempt +msi
It is possible to see the action RemoveExistingProducts in both logs but I can't tell if they worked or not.
https://bugs.winehq.org/show_bug.cgi?id=41269
--- Comment #16 from Reinhold reinhold.hoffmann@hotmail.com --- I have checked both logs and cannot see more whether the patch works or not.
In order to nail down the issue I have created a full package again including a tracing tool to explicitly see if the corrections are fine. Please see all in att. "Wine_bug_41296_Test_Scenario_Version_2.txt". For the simple tool see "Uninstall_Composer_check_Registry.cpp" for reference.
I hope this all is not too confusing and helps to get this issue fixed.
https://bugs.winehq.org/show_bug.cgi?id=41269
Reinhold reinhold.hoffmann@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #55585|0 |1 is obsolete| |
--- Comment #17 from Reinhold reinhold.hoffmann@hotmail.com --- Created attachment 55592 --> https://bugs.winehq.org/attachment.cgi?id=55592 Wine_bug_41296_Test_Scenario_Version_2
https://bugs.winehq.org/show_bug.cgi?id=41269
--- Comment #18 from Reinhold reinhold.hoffmann@hotmail.com --- Created attachment 55593 --> https://bugs.winehq.org/attachment.cgi?id=55593 Simple Uninstaller tool that checks Registry
https://bugs.winehq.org/show_bug.cgi?id=41269
--- Comment #19 from Hans Leidekker hans@meelstraat.net --- (In reply to Reinhold from comment #17)
Created attachment 55592 [details] Wine_bug_41296_Test_Scenario_Version_2
Are you sure the URL in this scenario points to the right installer? It fails to install here on 64-bit Windows 10. The error dialog mentions an "incorrect path".
https://bugs.winehq.org/show_bug.cgi?id=41269
--- Comment #20 from Reinhold reinhold.hoffmann@hotmail.com --- I just tested every step on Windows 10 64Bit and it works fine. Could you please email me (no post here) the log file of the installation which you can find
C:\Users\Public\Documents\Notation_3\Composer_3\Installation\Notation_Installation_LOG.log
and if it exists
C:\Users\Public\Documents\Notation_3\Composer_3\Installation\Notation_Software_LOG.log
and a screen shot of what you are seeing. Let's handle this issue via email until it is resolved. Sorry for any inconvenience.
https://bugs.winehq.org/show_bug.cgi?id=41269
--- Comment #21 from Hans Leidekker hans@meelstraat.net --- (In reply to Reinhold from comment #20)
I just tested every step on Windows 10 64Bit and it works fine. Could you please email me (no post here) the log file of the installation which you can find
C: \Users\Public\Documents\Notation_3\Composer_3\Installation\Notation_Installat ion_LOG.log
and if it exists
C: \Users\Public\Documents\Notation_3\Composer_3\Installation\Notation_Software_ LOG.log
and a screen shot of what you are seeing. Let's handle this issue via email until it is resolved. Sorry for any inconvenience.
Nevermind, I figured it out. It doesn't like being run from a network mounted drive.
https://bugs.winehq.org/show_bug.cgi?id=41269
Hans Leidekker hans@meelstraat.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #55580|0 |1 is obsolete| |
--- Comment #22 from Hans Leidekker hans@meelstraat.net --- Created attachment 55597 --> https://bugs.winehq.org/attachment.cgi?id=55597 patch
I don't get the repair/remove dialog on Windows. This dialog is gated by the condition Installed<>"", which will be true if the product is installed. If you run the first installer twice on Windows you get the same dialog. This must mean that RemoveExistingProducts runs the installer without UI.
Here's a patch that includes fixes for the 3 bugs we found so far.
https://bugs.winehq.org/show_bug.cgi?id=41269
--- Comment #23 from Bruno Jesus 00cpxxx@gmail.com --- (In reply to Hans Leidekker from comment #22)
Created attachment 55597 [details] patch
Here's a patch that includes fixes for the 3 bugs we found so far.
I can confirm that the new patch fixes the issue as well. No more repaor/remove dialog when upgrading from version 3 to 3.0.5.
https://bugs.winehq.org/show_bug.cgi?id=41269
--- Comment #24 from Reinhold reinhold.hoffmann@hotmail.com --- Thanks. That was a great interworking. Almost 24/7. Thanks for taking immediate action.
Have you been able to check that CustomAction installer failure ? ("Step 4: Verify if a failed installation properly de-installs and clears everything" of the att. Wine_bug_41296_Test_Scenario_Version_2)
https://bugs.winehq.org/show_bug.cgi?id=41269
--- Comment #25 from Hans Leidekker hans@meelstraat.net --- (In reply to Reinhold from comment #24)
Thanks. That was a great interworking. Almost 24/7. Thanks for taking immediate action.
Have you been able to check that CustomAction installer failure ? ("Step 4: Verify if a failed installation properly de-installs and clears everything" of the att. Wine_bug_41296_Test_Scenario_Version_2)
I don't see any custom action failure, with or without this patch.
https://bugs.winehq.org/show_bug.cgi?id=41269
--- Comment #26 from Bruno Jesus 00cpxxx@gmail.com --- Step 1 - Install 3.0.0 - OK Step 1.1 - Wine uninstaller shows 3.0.0 Step 1.2 - Composer Help->About shows 3.0.4 (???)
Step 2 - Install 3.0.5 over 3.0 - OK (no repair/remove)
Step 3.1 - Wine uninstaller shows 3.0.5 Step 3.2 - Composer Help->About shows 3.0.4 (???)
Can you please attach a compiled exe for step 4?
Files sha1sum: 232cc77ac609b4bf670fcc73011140f920884972 Inst_NS_Composer_3_English_Trial-3.0.0.msi d9fbfed2c0a16bb981d7b42387b5d7b1871d4390 Inst_NS_Composer_3_English_Trial-3.0.5.msi
https://bugs.winehq.org/show_bug.cgi?id=41269
--- Comment #27 from Reinhold reinhold.hoffmann@hotmail.com --- (In reply to Bruno Jesus from comment #26)
Step 1 - Install 3.0.0 - OK Step 1.1 - Wine uninstaller shows 3.0.0 Step 1.2 - Composer Help->About shows 3.0.4 (???)
Step 2 - Install 3.0.5 over 3.0 - OK (no repair/remove)
Step 3.1 - Wine uninstaller shows 3.0.5 Step 3.2 - Composer Help->About shows 3.0.4 (???)
That was probably the one from yesterday's first attachment which had in Help /About a 3.0.4.
The new attachment has new links. Please use exactly this link here which gives a full true 3.0.5 in the installer and Composer.exe Help/About
www.notation.com/download/Wine-test-bug41269/3.0.5/Inst_NS_Composer_3_English_Trial.msi
Can you please attach a compiled exe for step 4?
Please take the link from the attachement:
www.notation.com/download/Wine-test-bug41269/3.0.5-FailureInCustomAction/Inst_NS_Composer_3_English_Trial.msi
This is a special MSI where I artificially created a failure detection in the CustomActions. This failure needs to result in a rollback of the installation. Please see issue in attachment 2 Step 4.
Files sha1sum: 232cc77ac609b4bf670fcc73011140f920884972 Inst_NS_Composer_3_English_Trial-3.0.0.msi d9fbfed2c0a16bb981d7b42387b5d7b1871d4390 Inst_NS_Composer_3_English_Trial-3.0.5.msi
https://bugs.winehq.org/show_bug.cgi?id=41269
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #55588|0 |1 is obsolete| | Attachment #55589|0 |1 is obsolete| |
--- Comment #28 from Bruno Jesus 00cpxxx@gmail.com --- Created attachment 55600 --> https://bugs.winehq.org/attachment.cgi?id=55600 +msi with patch 2 and real 3.0.5 file
This new file does not install giving an error in Custom Action.
https://bugs.winehq.org/show_bug.cgi?id=41269
--- Comment #29 from Reinhold reinhold.hoffmann@hotmail.com --- Yes, correct. It was the intension that the installation fails by a failure intensionally created in CustomActions.
The issue is the following: When starting "wine unsinstaller" right after that failed installation it shows that "notation composer 3" is properly installed.
https://bugs.winehq.org/show_bug.cgi?id=41269
--- Comment #30 from Bruno Jesus 00cpxxx@gmail.com --- (In reply to Reinhold from comment #29)
Yes, correct. It was the intension that the installation fails by a failure intensionally created in CustomActions.
The issue is the following: When starting "wine unsinstaller" right after that failed installation it shows that "notation composer 3" is properly installed.
Indeed. I just tested in Windows XP and after the failed update the program is no longer in the add/remove. While in Wine it is still there.
https://bugs.winehq.org/show_bug.cgi?id=41269
--- Comment #31 from Reinhold reinhold.hoffmann@hotmail.com --- Thanks. This is a common issue like the one from Hans here in Comment 19 to 21.
In Hans' case the CustomAction has blocked installations from network drives (where we often have issues therefore we have blocked that). In that case the "Add/Remove" showed as if the app was properly installed. In order to proceed with a next installation the "faulty" needs to be manually uninstalled with "wine uninstaller".
We had many cases where customers were totally confused and we had fix that in remote sessions jointly with customers. That is very service intensive.
May be it is a new bug. I am glad you got it.
https://bugs.winehq.org/show_bug.cgi?id=41269
--- Comment #32 from Reinhold reinhold.hoffmann@hotmail.com --- Just want to add: According to the spec CustomAction DLLs can use MSI error codes as returns. The according error codes for MSI are defined in WinError.h from the range 1600 to 1699. The Wine installer needs to evaluate the return value which comes from the CustomActions DLL. Dependant of the error code, an appropriate actions needs to be taken.
https://bugs.winehq.org/show_bug.cgi?id=41269
--- Comment #33 from Hans Leidekker hans@meelstraat.net --- (In reply to Reinhold from comment #31)
May be it is a new bug. I am glad you got it.
Yes, that's bug number 4. Your test installer shows that a custom action failure should trigger a rollback too. It doesn't happen on Wine.
https://bugs.winehq.org/show_bug.cgi?id=41269
--- Comment #34 from Hans Leidekker hans@meelstraat.net --- (In reply to Hans Leidekker from comment #33)
(In reply to Reinhold from comment #31)
May be it is a new bug. I am glad you got it.
Yes, that's bug number 4. Your test installer shows that a custom action failure should trigger a rollback too. It doesn't happen on Wine.
Actually the rollback is started but not completed.
https://bugs.winehq.org/show_bug.cgi?id=41269
Hans Leidekker hans@meelstraat.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #55597|0 |1 is obsolete| |
--- Comment #35 from Hans Leidekker hans@meelstraat.net --- Created attachment 55604 --> https://bugs.winehq.org/attachment.cgi?id=55604 patch
This version includes fixes for all bugs identified so far. The issue with the custom action failure was that the rollback script didn't include a step to reverse the registry changes made by the PublishProduct action.
https://bugs.winehq.org/show_bug.cgi?id=41269
--- Comment #36 from Reinhold reinhold.hoffmann@hotmail.com --- Thanks for the immediate actions. I think this will further brings Wine to a robost level.
I cannot create a patched version to verify all the changes. Is there a possibility to receive a pre-packaged build that I can do some hard-testing?
I have Ubuntu LTS 16.14 and openSuSE 13.2 available each one of the latest package status available.
https://bugs.winehq.org/show_bug.cgi?id=41269
--- Comment #37 from Bruno Jesus 00cpxxx@gmail.com --- (In reply to Hans Leidekker from comment #35)
Created attachment 55604 [details] patch
This version includes fixes for all bugs identified so far. The issue with the custom action failure was that the rollback script didn't include a step to reverse the registry changes made by the PublishProduct action.
With this patch the program no longer appear in the wine uninstaller, so I believe it fixes the last issue that was remaining.
(In reply to Reinhold from comment #36)
I cannot create a patched version to verify all the changes. Is there a possibility to receive a pre-packaged build that I can do some hard-testing?
I have Ubuntu LTS 16.14 and openSuSE 13.2 available each one of the latest package status available.
I don't know if I could just ship the compiled msi DLL or not, I believe Hans may have a better idea.
https://bugs.winehq.org/show_bug.cgi?id=41269
--- Comment #38 from Hans Leidekker hans@meelstraat.net --- (In reply to Bruno Jesus from comment #37)
I have Ubuntu LTS 16.14 and openSuSE 13.2 available each one of the latest package status available.
I don't know if I could just ship the compiled msi DLL or not, I believe Hans may have a better idea.
You can try, but compiling Wine shouldn't too hard for someone who can build MSI installers ;-)
https://bugs.winehq.org/show_bug.cgi?id=41269
--- Comment #39 from Reinhold reinhold.hoffmann@hotmail.com --- (In reply to Hans Leidekker from comment #38)
(In reply to Bruno Jesus from comment #37)
I have Ubuntu LTS 16.14 and openSuSE 13.2 available each one of the latest package status available.
I don't know if I could just ship the compiled msi DLL or not, I believe Hans may have a better idea.
You can try, but compiling Wine shouldn't too hard for someone who can build MSI installers ;-)
Yes, I agree. Could not be more complex...
However, my focus is to provide cool stuff for musicians :-)
I have disabled the links to download those demo versions because I want to avoid that pre-mature stuff can be downloaded from our website. If you still need them please let me know. I keep all in place until I will have verified the fixes when the corrections will be available in an official distribution. Hope it will not take too long. Just yesterday we had another guy who ran into one of those.
Thanks a lot.
https://bugs.winehq.org/show_bug.cgi?id=41269
--- Comment #40 from Reinhold reinhold.hoffmann@hotmail.com --- Just want to bring up from my Comment 3 here and double-check ifthe patch covers this situation:
"A final solution also need to handle the situation that existing screwed Registry entries need to be cleaned up."
Just some more explanation to that: Any MSI apps that has been installed prior to the correction of bug 41269 may have left the Registry screwed (old UpgradeCode and old ProductCode exist) in case no new Wineprefix is selected. Windows MSI calls like "MsiEnumRelatedProduct" check those old Registry entries and dependant on the existance certain actions are taken or not.
The fix of this bug needs to deal with screwed Registry entries and has to clean up those old UpgradeCode and old ProductCode. It cannot be expected that each Wine user starts with a fresh Wine installation.
https://bugs.winehq.org/show_bug.cgi?id=41269
--- Comment #41 from Bruno Jesus 00cpxxx@gmail.com --- (In reply to Reinhold from comment #40)
Just some more explanation to that: Any MSI apps that has been installed prior to the correction of bug 41269 may have left the Registry screwed (old UpgradeCode and old ProductCode exist) in case no new Wineprefix is selected. Windows MSI calls like "MsiEnumRelatedProduct" check those old Registry entries and dependant on the existance certain actions are taken or not.
The fix of this bug needs to deal with screwed Registry entries and has to clean up those old UpgradeCode and old ProductCode. It cannot be expected that each Wine user starts with a fresh Wine installation.
Do you have an installer that triggers such corruption on Windows and a second installer that proves Windows clear the bad data automatically?
https://bugs.winehq.org/show_bug.cgi?id=41269
--- Comment #42 from Reinhold reinhold.hoffmann@hotmail.com --- No I have not aware of such a function in Windows.
The inconsistany in the Registry with Wine comes from this bug. - even when this bug is corrected an existing Wine Registry stays inconsistant - only a new Wine setup AND with new installations of all those MSI apps the Registry becomes clean ( and, of course, for a a new WINEPREFIX)
In order to get a clean Registry with an existing Wine installation when updating the corretion, does Wine need to be newly installed AND all apps? My view: cannot be the solution.
Alternatively, at the Wine installation with the corrections a somehow "audit" function needs to be added to clean the Registry inconsistancy.
I think an answer needs to be provided with the correction. Or if Wine offers such capabilities, please let me know.
https://bugs.winehq.org/show_bug.cgi?id=41269
--- Comment #43 from Nikolay Sivov bunglehead@gmail.com --- (In reply to Reinhold from comment #42)
No I have not aware of such a function in Windows.
The inconsistany in the Registry with Wine comes from this bug.
- even when this bug is corrected an existing Wine Registry stays
inconsistant
- only a new Wine setup AND with new installations of all those MSI apps the
Registry becomes clean ( and, of course, for a a new WINEPREFIX)
In order to get a clean Registry with an existing Wine installation when updating the corretion, does Wine need to be newly installed AND all apps? My view: cannot be the solution.
Alternatively, at the Wine installation with the corrections a somehow "audit" function needs to be added to clean the Registry inconsistancy.
Normally we don't do that - if a wine bug causes inconsistent wineprefix state, and bug is fixed eventually, suggested way is to remove wineprefix and start over.
I think an answer needs to be provided with the correction. Or if Wine offers such capabilities, please let me know.
https://bugs.winehq.org/show_bug.cgi?id=41269
--- Comment #44 from Reinhold reinhold.hoffmann@hotmail.com --- Thanks for the immediate response.
Starting all over would be a broad impact to many users because many MSI apps would need to be re-installed. Unfortunately users don't know whether they are impacted or not. It is really a tricky situation if no "audit" will be available. At least a clear notification would be required in the release notes.
Hope that my comments helped to make the implications clear.
https://bugs.winehq.org/show_bug.cgi?id=41269
Reinhold reinhold.hoffmann@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |major
--- Comment #45 from Reinhold reinhold.hoffmann@hotmail.com --- Due to the broad impact of users when no Registry audit clean up is available, I took the liberty to raise the importance to "major".
Because of the implications to users (all relevant apps need to be re-installed) I believe a solution needs to be available in the stable line 1.8 the sooner the better.
https://bugs.winehq.org/show_bug.cgi?id=41269
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|major |normal
https://bugs.winehq.org/show_bug.cgi?id=41269
--- Comment #46 from Hans Leidekker hans@meelstraat.net --- Several patches have been committed to address the bugs identified here. Please test the latest release.
https://bugs.winehq.org/show_bug.cgi?id=41269
Reinhold reinhold.hoffmann@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|NEW |RESOLVED
--- Comment #47 from Reinhold reinhold.hoffmann@hotmail.com --- Last but not least, I have tested the scenario with Wine 2.0.3 and Wine 2.22. Although there are still some installer issues (Bug 41361, Bug 44121) this one in fixed. The Registry is clean after an aplication is uninstalled.
Thanks to all who helped here.
https://bugs.winehq.org/show_bug.cgi?id=41269
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #48 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 3.0-rc1.
https://bugs.winehq.org/show_bug.cgi?id=41269
Reinhold reinhold.hoffmann@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|FIXED |--- Status|CLOSED |REOPENED Version|1.9.18 |3.19
--- Comment #49 from Reinhold reinhold.hoffmann@hotmail.com --- This bug was fixed in Wine greater 2.0.3 and was OK in Wine-3.0 a year ago. But it is open again in Wine-3.19.
Scenario:
(1) A Windows app with version e.g. 3.1.7 is installed (2) An new version of this app e.g. 3.1.21 gets installed with same UpgradeCode but different Product- and PackageCode and with the directive "RemoveExistingProducts" in the installation sequence BEFORE the new installation.
PROBLEM: The new 3.1.21 does not get installed automatically. In the installation process the windows comes up again whether the former 3.1.7 should be Repaired or Removed. After Repair or Remove the former version gets uninstalled and the installer terminates without installing the new 3.1.21.
BUT teh installation of 3.1.21 needs to be started again.
Two years ago (Nov. 2016) we ran through a long and somehow painful discussion and fixed the scenarion in Wine greater than 2.0.3. Also, Wine 3.0 worked fine.
But the bug is open again in Wine 3.19
https://bugs.winehq.org/show_bug.cgi?id=41269
Hans Leidekker hans@meelstraat.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|REOPENED |RESOLVED
--- Comment #50 from Hans Leidekker hans@meelstraat.net --- Please don't recycle bug reports. The subject of this bug (uninstall does not clean up upgrade/product codes) was addressed with a patch and confirmed fixed by you.
Please open a new bug report for the issue you're seeing now.
https://bugs.winehq.org/show_bug.cgi?id=41269
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #51 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 3.20.
-
wine-bugs＠winehq.org