I am trying to get some custom actions working properly on my install.
This is the table I am using for my logic in Wix (provided by ahmd0)
The problem is that it just doesn't seem to be working. Here are my conditions currently:
<Custom Action='RemoveService' After='InstallInitialize'>Installed</Custom>
<Custom Action='WaitForFileLocks' After='InstallInitialize'>Installed</Custom>
<Custom Action='InstallService' Before='InstallFinalize'>NOT REMOVE ~= "ALL" OR UPGRADINGPRODUCTCODE</Custom>
<Custom Action='MergeConfigFiles' Before='InstallFinalize'>NOT REMOVE ~= "ALL" OR UPGRADINGPRODUCTCODE</Custom>
The behavior I expect from this:
RemoveService and WaitForFileLocks should be run on uninstalls and upgrades.
InstallService and MergeConfigFiles should be run on installs and upgrades.
The behavior I am seeing:
RemoveService and WaitForFileLocks are running on uninstall, but NOT upgrades.
InstallService and MergeConfigFiles is being run on install, but NOT upgrades.
Is the table I am using wrong? Is my logic correct? Could my issue be Windows' recognition of what an "upgrade" is? I checked in Add/Remove programs after I increased all 3 version numbers for my install and the new version is properly updating there.
Related
I am using the following code to start a Setup program at the end of my Installation (also with elevated permissions):
<Product ... >
...
<InstallExecuteSequence>
<Custom Action='LaunchSetupAction' After='InstallFinalize'/>
</InstallExecuteSequence>
<!-- Workaround required for Windows7, Setup.exe can not be started directly because of UAC
http://stackoverflow.com/questions/2325459/executing-a-custom-action-that-requires-elevation-after-install -->
<Property Id="WixShellExecTarget" Value='[#SetupEXE]'/>
<CustomAction Id="LaunchSetupAction" BinaryKey="WixCA" DllEntry="WixShellExec" Execute="immediate" Return="check" Impersonate="yes"/>
...
<MajorUpgrade DowngradeErrorMessage="A later version of [ProductName] is already installed. Setup will now exit." />
</Product>
This works well when then program is installed freshly, but when it is upgraded from a previous version with the same code, the installation reports a fatal error and fails.
In the Windows installer log I have found the following:
Action start 23:42:22: LaunchSetupAction.
...
MSI (s) (38:88) [23:42:22:342]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI679.tmp, Entrypoint: WixShellExec
...
WixShellExec: WixShellExecTarget is C:\Program Files\Me\MySetup.exe
...
WixShellExec: Error 0x80070002: ShellExec failed with return code 2
...
WixShellExec: Error 0x80070002: failed to launch target
...
Action ended 23:42:22: LaunchSetupAction. Return value 3.
Action ended 23:42:22: INSTALL. Return value 3.
Interesting enough these error messages (file not found?) is also there when I comment out the CustomAction in the new version of the installer.
Why is this CustomAcount executed from the previous version to be uninstalled?
Is there any way I can stop it from being run? After a certain point of the upgrade, the MySetup.exe is just not there anymore and will always cause a fatal error ...
That custom action has no condition on it, so it will be called on all types of installer operations, such as uninstall, add/remove features etc. Your upgrade is an install of the new product and an uninstall of the old product.
You need this kind of thing on your custom action:
Wix: Run custom action based on condition
so a condition of 'Not Installed' causes the CA to run only if the product is not already installed.
You can't really fix this because the uninstall for that product is embedded in the system. You'd need to fix that older version of the product by rebuilding the exact same product with the custom action condition fixed and then fix it with:
msiexec /i [path to new MSI] REINSTALL=ALL REINSTALLMODE=vomus
If you're very familiar with MSI and Orca, you may be able to locate the cached MSI file in C:\windows\installer, open it with Orca, go the InstallExecuteSequence and give that custom action a condition of 0, then save it. That basically corrects the uninstall sequence so that your upgrade will work. Caveat Emptor.
It also appears that a plain uninstall would give you same error - did you every try to do an uninstall test?
I'm using wix installer (version 3), I have an msi of version 1.99 and another msi of version 2.00. My app has the ability to do import and export of the DB by calling it with some arguments. I'm trying to perform a major upgrade, and trying to call custom actions before and after the upgrade.
Now, the custom action code works just fine. The problem is, that the code that should run BEFORE the old version is removed, is running AFTER it is removed, and thus cannot activate the app and produce the backup files.
In short: How do I time the custom actions to do their work before the removal of the old version?
This is how I call them:
<CustomAction Id="doExport"
Return="check"
Execute="immediate"
BinaryKey="ImportExportBinary"
DllEntry="BeforeInstall" />
<CustomAction Id="doImport"
Return="check"
Execute="immediate"
BinaryKey="ImportExportBinary"
DllEntry="AfterInstall" />
<InstallExecuteSequence>
<Custom Action="doExport" Before="InstallInitialize"> NOT Installed</Custom>
<Custom Action="doImport" After="InstallFinalize"> NOT Installed</Custom>
</InstallExecuteSequence>
EDIT:
Here is the major upgrade code:
<MajorUpgrade AllowDowngrades="no"
Schedule="afterInstallFinalize"
DowngradeErrorMessage='Cannot downgrade!'
AllowSameVersionUpgrades='yes' ></MajorUpgrade>
I've tried playing a bit with "Execute" attribute of the CustomAction element, without any results.
First, do your upgrade creating a verbose log to make sure your custom actions are working and being called. You've marked them immediate, so they run before anything changes on the system and so will be called before the old product is removed. When you say "the code works just fine" you probably mean when you run it from your interactive account. But that's not happening. Your code is running out of an msiexec.exe process, the working directory is not what you expect, your code may not be looking in the right place for the files, it will not be elevated and so may not be able to do what it thinks it can. There are many opportunities for your code to not work as expected.
If you ever marked them as deferred I can see why doExport might not work. Without seeing your MajorUpgrade element I can't be sure, but the default scheduling for RemoveExistingProducts is afterInstallValidate. Your custom action is before InstallInitialize, so the actual sequence in the MSI file could easily be InstallValidate, RemoveExistingProducts, doExport, InstallInitialize.
and RemoveExistingProducts that does the uninstall of the old version is before your custom actions.
So if you want to use execute deferred, try Before="RemoveExistingProducts" on your doExport, or use Schedule in your MajorUpgrade to afterInstallInitialize and keep your doExport before InstallInitialize.
I tryied the same thing, and it took me long to find a way for it to work.
You can use
<Custom Action="doExport" Before="RemoveExistingProducts"></Custom>
The option RemoveExistingProducts refers to the action of uninstalling the existing version of your product, so you have to execute the action before the existing version is removed.
I did not find this option in this list: https://learn.microsoft.com/en-us/windows/win32/msi/suggested-installexecutesequence
But it seems to work, and executes before the list of options described in the link.
About the options which should go inside the <Custom></Custom> tag, I am not sure, but I hope it helps to start the code at the right moment.
I have two custom actions, one of which I'd like to execute when my product is installed and the other when it is uninstalled.
My custom action is currently called from a merge module after the "InstallFinalize", but this happens for both install and uninstall. I've tried adding the "NOT INSTALLED AND NOT UPGRADINGPRODUCTCODE" condition, but that gave me an error:
Error 2762. Cannot write script record. Transaction not started.
I've also tried attaching to other actions (for example, UnpublishComponents), but I can't find any that are unique to install or uninstall.
How can I fix this problem?
Try next
1. Only for Installation:
<InstallExecuteSequence>
<Custom Action="SomeAction" After="InstallFinalize">NOT Installed AND NOT REMOVE</Custom>
</InstallExecuteSequence>
2. For Uninstall try to use: Rob's answer
UPGRADINGPRODUCTCODE property is set only during RemoveExistingProducts CA.
The variable “INSTALLED” should be using is “Installed”. Find more information regarding the Install and uninstall conditions in the Stack Overflow answer How to add a WiX custom action that happens only on uninstall (via MSI)?.
I'm trying to run a custom action on first install and any subsequent modification(adding/removing features of the installed product).
Which condition should I check?
I'm using the following but it doesn't work.
<InstallExecuteSequence>
<Custom Action='SetParams' After='InstallFinalize'>NOT Installed OR WixUI_InstallMode = "Change"</Custom>
</InstallExecuteSequence>
Thanks
You can try this condition:
REMOVE <> "ALL"
It's true for a first time install and any maintenance operation except uninstall.
We have a custom action that we want to run ONLY on a major upgrade. Trouble is, the CA is deferred because it needs access to system files (it removes the old version of the program from an INI file). Because the CA is deferred, it only has access to the CustomActionData property.
So my first attempt was to set CustomActionData if UPGRADINGPRODUCTCODE was true, and then condition the CA that actually did the upgrade on CustomActionData. That failed--CustomActionData was not set, I assume because it's only visible within the custom action and not usable as a condition for the custom action.
Here are the CA's I defined:
<CustomAction Id="MyCA.SetProperty" Return="check" Property="MyCA"
Value="[UPGRADINGPRODUCTCODE]" />
<CustomAction
Id="MyCA"
BinaryKey="MyIniProcessingProgram"
ExeCommand="MyArgs"
Execute="deferred"
Impersonate="no"
Return="ignore"/>
And here is my InstallExecuteSequence:
<RemoveExistingProducts After="InstallValidate" />
<Custom Action="MyCA.SetProperty" Before="InstallFinalize"/>
<Custom Action="MyCA" After="MyCA.SetProperty">
CustomActionData
</Custom>
I have also tried:
Making MyCA.SetProperty conditional on UPGRADINGPRODUCTCODE, then scheduling MyCA after it--doesn't work because even if MyCA.SetProperty doesn't run, the "After" action does.
It would be best if we could avoid JavaScript/VBScript actions, or resort to checking the value of CustomActionData within the INI-updating program itself; the idea is to make the CA itself conditional, so we don't launch it unless the condition (major upgrade) is true.
Why not use this custom action:
<CustomAction
Id="MyCA"
BinaryKey="MyIniProcessingProgram"
ExeCommand="MyArgs"
Execute="deferred"
Impersonate="no"
Return="ignore"/>
with this InstallExecuteSequence?
<Custom Action="MyCA" After="InstallValidate">
UPGRADINGPRODUCTCODE
</Custom>
Please note that UPGRADINGPRODUCTCODE is set in the package which is being upgraded, so it's available only in the uninstall process of the old version.
If you want to detect an upgrade in your new version, you can use the ActionProperty column in Upgrade table:
http://msdn.microsoft.com/en-us/library/aa372379(VS.85).aspx
Basically, you need to define the upgrade rules for older and newer versions:
http://wix.sourceforge.net/manual-wix2/wix_xsd_upgradeversion.htm
This way you can detect older versions through a custom property. This property can then be used to condition your custom action.
The conditions used to gate any action (deferred included) are those of the immediate sequence. That means you could use UPGRADINGPRODUCTCODE directly as part of the condition on even your deferred action.
When the installer reaches this sequence during the immediate phase, it will evaluate the condition, and schedule the deferred execution if the condition is true. Then when it runs the deferred sequence, it will just run all the actions that were scheduled during the immediate phase.