Jump to content


This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Photo

Rollback failed in cancelling a major upgrade


7 replies to this topic

dxue

dxue
  • Full Members
  • 33 posts

Posted 16 June 2005 - 19:50

Hi Stefan and other friends,

I am having problems with the major upgrade project I am authoring. The biggest problem is that rollback isn't working properly when the ongoing major upgrade is cancelled at somepoint during the installation. When this happens, I see the new product has been installed regardless the cancellation.

I have put the RemoveExistingProduct action after InstallFinalize event. I am doing inplace updating. Unfortunately, the installation log is too big to attach, so I only paste the very last part of it:

MSI (s) (70:EC) [22:53:49:093]: Error in rollback skipped. Return: 5
MSI (s) (70:EC) [22:53:49:109]: No System Restore sequence number for this installation.
MSI (s) (70:EC) [22:53:49:109]: Unlocking Server
MSI (s) (70:EC) [22:53:49:109]: PROPERTY CHANGE: Deleting UpdateStarted property. Its current value is '1'.
Action ended 22:53:49: INSTALL. Return value 2.
Action ended 22:53:49: RemoveExistingProducts. Return value 2.
Action ended 22:53:49: INSTALL. Return value 2.
MSI (s) (70:7C) [22:53:49:187]: MainEngineThread is returning 1602
MSI (s) (70:7C) [22:53:49:187]: Destroying RemoteAPI object.
MSI (s) (70:30) [22:53:49:187]: Custom Action Manager thread ending.
MSI © (E8:B4) [22:53:49:343]: Back from server. Return value: 1602
MSI © (E8:B4) [22:53:49:343]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1
MSI © (E8:B4) [22:53:49:343]: PROPERTY CHANGE: Deleting SECONDSEQUENCE property. Its current value is '1'.
Action ended 22:53:49: ExecuteAction. Return value 2.
MSI © (E8:B4) [22:53:49:343]: Doing action: SetupInterrupted
Action start 22:53:49: SetupInterrupted.
DEBUG: Error 2836: The control Restore on the dialog SetupInterrupted can not take focus
Internal Error 2836. SetupInterrupted, Restore
Action ended 22:53:52: SetupInterrupted. Return value 2.
Action ended 22:53:52: INSTALL. Return value 2.
MSI © (E8:B4) [22:53:52:609]: Destroying RemoteAPI object.
MSI © (E8:E0) [22:53:52:750]: Custom Action Manager thread ending.
=== Logging stopped: 6/15/2005 22:53:52 ===
MSI © (E8:B4) [22:53:52:765]: Note: 1: 1708
MSI © (E8:B4) [22:53:52:765]: Product: spm toot 3.0 -- Installation operation failed.

MSI © (E8:B4) [22:53:52:796]: Grabbed execution mutex.
MSI © (E8:B4) [22:53:52:796]: Cleaning up uninstalled install packages, if any exist
MSI © (E8:B4) [22:53:52:812]: MainEngineThread is returning 1602
=== Verbose logging stopped: 6/15/2005 22:53:52 ===

Please help me identify the cause of the problem.

Thanks very much,

Dong

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 17 June 2005 - 12:33

MSI help about placement of the RemoveExistingProducts action:
QUOTE
After the InstallFinalize action. This is the most efficient placement for the action. In this case, the installer updates files before removing the old applications. Only the files being updated get installed during the installation. If the removal of the old application fails, then the installer only rolls back the uninstallation of the old application.

So what you are seeing is the expected behaviour.

dxue

dxue
  • Full Members
  • 33 posts

Posted 20 June 2005 - 19:59

Thanks Stefan for your fast response. The Windows Installer documentation mentions that it will generate rollback script for all the actions executed in between InstallInitial and InstallFinialize. For my case, I want the installer to roll back from the failed or cancelled installation of new version to the state where the original version of the application was installed. So I have to place the RemoveExistingProduct ealirer than InstallFinalize. If my installer doesn't contain any custom actions that directly change system, is this rollback always possible? Does the way how my installer follows the component rules have impact on this?

Thanks again for your advice.

Dong

dxue

dxue
  • Full Members
  • 33 posts

Posted 21 June 2005 - 06:36

Further, say I have a deployed module myexe.dll, which is not shared and installed in mycompany\myapplication\bin. The original version is 1.0.0. Now, I apply a major upgrade over this version. In the newer version, ProductCode, ProductVersion, and PackageCode have been changed, while UpgradeCode is kept intact. In the new version, I don't change the filename and deploy path to myexe.dll file, nor the ComponentCode. Is this problematic in terms of enabling a proper rollback?

dxue

dxue
  • Full Members
  • 33 posts

Posted 21 June 2005 - 08:46

Interesting! I made a little test. I created an simple installer, which contains one component that deploys windowsapplication4.exe to ProgramFiles\mycompany\bin folder on target system. In version 5.0 of the installer, I followed closely the component creation rules and rules for major upgrade installation. Specificlly, I changed the filename, deployment destination, ComponentCode of the exe. I now have windowsapplication5.exe installed to ProgramFiles\mycompany root folder. By the way, only upgradecode was kept intact. I first installed verion 4.0, then applied version 5.0. Right before the exit of the InstallProgress dialog, I clicked on cancel button to cancel the installation. I did get Installation interrupt dialog, which says my system hasn't been changed. But when looking at the program files folder, the application is either completely removed or bother versions are present. So the rollback didn't work! This time I placed RemoveExistingProducts in between InstallInitialize and InstallFinalize. I have attached the verbose log zip file. Please help.

Attached Files

  • Attached File  as1.zip   20.78KB   192 downloads


Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 21 June 2005 - 13:58

It looks like FindRelatedProducts didn't find anything and therefore RemoveExistingProducts is not doing anything. In other words: this is not a major upgrade. However the ISSetAllUsers custom action apparently detects that this is a major upgrade. This is weired.
I get the feeling that debugging your project requires more information and more work than can be done here in the forum.
Also I'm not quite sure what you are really trying to achive. Maybe re-read that doc section about placement of the RemoveExistingProducts action. Note that the part I quoted talks about a failure during the uninstall of the old version. I'm not sure you can trigger such a failure by clicking the Cancel button.

dxue

dxue
  • Full Members
  • 33 posts

Posted 21 June 2005 - 17:58

I read the MSI documentation:

QUOTE
Between the InstallExecute action, or the InstallExecuteAgain action, and the InstallFinalize action. Generally the last three actions are scheduled right after one another: InstallExecute, RemoveExistingProducts, and InstallFinalize. In this case the updated files are installed first and then the old files are removed. However, if the removal of the old application fails, then the installer rolls back both the removal of the old application and the install of the new application.


This looks what I want for rollback, but I could not find InstallExecute and InstallExecuteAgain actions in the sequence table. I am using InstallShield DevStudio 9.

dxue

dxue
  • Full Members
  • 33 posts

Posted 21 June 2005 - 23:55

Never mind, I've found it. InstallExecute and InstallExecuteAgain are not present in the InstallShield Designer by default. They can be inserted. Thanks anyway.