Rollback custom action after pressing Cancel button

Nov 23, 2015 at 12:17 PM
Edited Nov 23, 2015 at 12:57 PM
Hi,

I have a rollback custom action which is not executed in case of a rollback caused by pressing the Cancel button.
The rollback custom action is defined between InstallInititialize and InstallFinalize actions.
I get the message:
MSI (s) (34:30) [14:34:27:181]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI9D2C.tmp, Entrypoint: RollbackUpdateDatabase
SFXCA: Extracting custom action to temporary directory: C:\WINDOWS\Installer\MSI9D2C.tmp-\
SFXCA: Binding to CLR version v4.0.30319
Calling custom action CustomActions.RollbackUpdateDatabase
Exception while loading custom action:
Action14_RollbackUpdateDatabase returned actual error code 1603 but will be translated to success due to continue marking
The RollbackUpdateDatabase method signature seems ok in code.
        [CustomAction]
        public static ActionResult RollbackUpdateDatabase(Session session)
I mention that I tried to set Impersonate property on rollback custom action to both values: true and false, with the same bad result.

Any ideea why the rollback custom action did not run when pressing Cancel button during install?
Coordinator
Nov 24, 2015 at 2:51 AM
It seems like it is not a failure in the action itself but rather a problem during with WiX runtime trying to load the custom action (e.g. referenced assemblies are missing).

The easiest way to test it is to have your custom action body completely empty (may be with only a session.Log("something")). If it works then it is a dependency problem and it will need to be fixed by defining the referenced assemblies (e.g. project.DefaultRefAssemblies.Add). Unless of course it is some other dependency problem.
Dec 3, 2015 at 1:03 PM
I did some more tests, and here are my findings when pressing Cancel button on Progress dialog:
  • My rollback custom actions are not executed because the referenced assemblies are not extracted from msi. For exemple, if the log says
SFXCA: Extracting custom action to temporary directory: C:\WINDOWS\Installer\MSI9D2C.tmp-\
the C:\WINDOWS\Installer\MSI9D2C.tmp-\ folder is not created on disk. I mention that all temporary folders created for running the normal custom actions, before presssing Cancel button, exist on disk.
  • On upgrade rollback, the ExecXmlFileRollback action (it is not mine), which is supposed to modify an xml file, throws error:
MSI (s) (D8:98) [14:46:00:498]: Executing op: ActionStart(Name=ExecXmlFileRollback,,)
MSI (s) (D8:98) [14:46:00:501]: Executing op: CustomActionRollback(Action=ExecXmlFileRollback,ActionType=3329,Source=BinaryData,Target=ExecXmlFileRollback,CustomActionData=0€C:\Program Files (x86)\MyCompany\MyApp\web.config€
MSI (s) (D8:AC) [14:46:00:508]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSIB793.tmp, Entrypoint: ExecXmlFileRollback
ExecXmlFileRollback:  Entering ExecXmlFileRollback in C:\WINDOWS\Installer\MSIB793.tmp, version 3.10.2103.0
ExecXmlFileRollback:  Error 0x80070002: Failed to get modified date of file C:\Program Files (x86)\MyCompany\MyApp\web.config.
CustomAction ExecXmlFileRollback returned actual error code 1602 but will be translated to success due to continue marking
For now, I will disable the Cancel button on Progress dialog.
Coordinator
Dec 3, 2015 at 10:50 PM
> ...the C:\WINDOWS\Installer\MSI9D2C.tmp-\ folder is not created on disk.
Yes indeed it does look like a SFXCA problem. If you really want to get at the bottom of it you may want to log the defect at WiX wiki. The easiest way to do this is to call BuildMsiCmd and this will produce a batch file that will only use WiX tools and your wxs sources. This way your test case will not be polluted with Wix# logic and this WiX friendlier version will be easier to deal with for the WiX guys.

> I mention that all temporary folders created for running the normal custom actions, before presssing Cancel button, exist on disk.
I am not sure it is true. I have observed very different behavier. WiX SFXCA runtime creates a fully self sufficient temporary dir for every single CA even if the action is using the same set of dlls.