In the process of converting from installshield to wix, I am porting over the custom actions.
One is for determining previously installed versions and popping up a message if any are found. I guess the guids weren't properly tracked before.
Within installshield, it appears they had the CA scheduled after ValidateProductID. I tried to do the same:
<CustomAction Id="CA_CheckPreviousVersions.SetProperty" Property="CA_CheckPreviousVersions" Value="ERROR_UNINSTALL_VERSION=$(var.ERROR_UNINSTALL_VERSION)" />
<CustomAction Id="CA_CheckPreviousVersions" DllEntry="CheckPreviousVersions" Execute="deferred" BinaryKey="LunaClientCustomActions_dll" />
<InstallExecuteSequence>
...
<Custom Action="CA_CheckPreviousVersions.SetProperty" After="ValidateProductID" />
<Custom Action="CA_CheckPreviousVersions" After="CA_CheckPreviousVersions.SetProperty" >NOT Installed AND NOT PATCH</Custom>
</InstallExecuteSequence>
Except, I get a nasty warning:
error LGHT0204: ICE77: CA_CheckPreviousVersions is a in-script custom action. It must be sequenced in between the InstallInitialize action and the InstallFinalize action in the InstallExecuteSequence table
Why am I getting this, whereas IS seemingly permitted it? More to the point, how do I replicate the behaviour that was previously in place?
You haven't shown the custom action definition, but the message indicates it's deferred and must be sequenced as the message indicates. Perhaps the original type was immediate.
If you mean previously installed versions of your product (or in fact any MSI-based product for which you know the UpgradeCode) there is no need for any code. If you were to use a WiX MajorUpgrade element you can detect previous versions because the WIX_UPGRADE_DETECTED property will be set, and you could use that as a launch condition, or whatever it is you plan to do. Or use Upgrade and UpgradeVersion elements to detect previous versions and version ranges. From what you've said there seems no need to run code. Just use the upgrade search properties and show dialogs or errors or whatever.
Related
I have a variable in my burn bundle as such:
<Variable Name="DemoVariable" Type="string" Value="ChangedProperty" bal:Overridable="yes"/>
Which is then used with an MSIProperty:
<MsiPackage SourceFile="testFile.msi" Id="DemoPackageId_1" Cache="yes" Visible="no">
<MsiProperty Name="PassedProperty" Value="[DemoVariable]"/>
</MsiPackage>
In my testFile.msi I have a property and custom action:
<Property Id="PassedProperty" Value="Unchanged"/>
<Binary Id="CustomActionDll"
SourceFile="CustomAction.CA.dll"/>
<InstallExecuteSequence>
<Custom Action="ShowMessageBoxCA" Before="CostFinalize"/>
</InstallExecuteSequence>
<CustomAction Id="ShowMessageBoxCA"
Return="check"
Execute="firstSequence"
BinaryKey="CustomActionDll"
DllEntry="ShowMessageBox"
HideTarget="no" />
The ShowMessageBox function literally just calls:
MessageBox.Show(session["PassedProperty"])
The problem is that the message box shows the message "unchanged". I looked through the log file for the installation and I can see that the PassedProperty is being changed sometime after InstallFinalize finishes. This is obviously too late for my custom action which takes place before CostFinalize.
Is there a way to make Burn change the MSIProperty earlier in the process rather than making the custom actions take place later?
Edit:
Okay so I found the answer but I can't post it yet so I'll leave the information here in an edit.
Basically MSI's have Public and Private properties. Only public properties are declared before the install phase takes place. Public properties must be all uppercase so to fix my issue I just replaced all instance of "Passed_Property" with "PASSED_PROPERTY" and it works fine.
So the problem I had was that I was creating my properties as private properties, which aren't available until after the installation. To make your properties public and therefore available throughout the whole install, they need to be Uppercase.
<Property Id="PASSED_PROPERTY" Value="Unchanged"/>
https://msdn.microsoft.com/en-us/library/aa370912(v=vs.85).aspx
As soon as I made them public the properties were changed by Burn.
I have an .exe embedded inside my MSI installer which I'd like to somehow call directly from the installer, before the the 'InstallFiles' action occurs.
It's defined as follows:
<CustomAction Id="LaunchInstallManager_TryUninstall" Return="ignore" Directory="INSTALLFOLDER" Execute="deferred" Impersonate="no" ExeCommand=""[#fil713F8F6A7BC9B98857D779B9B29873E1]" /someargument"></CustomAction>
<Custom Action="LaunchInstallManager_TryUninstall" Before="InstallFiles">NOT Installed</Custom>
But upon looking at the logs, it looks like it's (trying to be) called from the install destination.
Is such a thing possible?
It is possible, but in a different way. The 'run EXE' type of custom action will always search for the executable on the target system. Thus, if your executable is installed along with your app, it is not an option.
Here is another way:
First, author your EXE as a <Binary> instead.
It is as easy as <Binary Id="MyEXE" SourceFile="PATH\TO\EXE" />.
Add a DLL deferred custom action, which will extract the binary, run it with parameters and clean up afterwards.
This post can give you an idea how to extract the binary using C# and DTF. Besides, in case you need to pass parameters, make sure you do it the right way for deferred custom action.
Finally, remember that each deferred custom action (that is the one to change the target system) must have corresponding rollback action. This article might give you some hints on how to test the direct and rollback behaviors of your custom actions.
How to sequence a custom action to execute only when installation is interrupted or completed with error?
Is there any windows installer property which returns current installation status (failed/succeed)?
The OnExit attribute of the <Custom> element is what you're looking for. It is mutually exclusive with Before, After, and Sequence attributes and can have the following values: success, cancel, error, suspend.
UPDATE: basically, this is what I mean:
1) Define a custom action which will do the work you'd like it to do (gather some failure data). Note that you'll have to define N custom actions pointing to the same target because the CustomAction MSI table expects Id as a primary key (let's assume it's DLL CA):
<CustomAction Id="LogFailureOnCancel" BinaryKey="CustomActions" DllEntry="LogFailure" ... />
<CustomAction Id="LogFailureOnError" BinaryKey="CustomActions" DllEntry="LogFailure" ... />
NOTE: both definitions point to the same real action (DllEntry attribute).
2) Schedule these custom actions appropriately:
<Custom Action="LogFailureOnCancel" OnExit="cancel" />
<Custom Action="LogFailureOnError" OnExit="error" />
To the extent that Windows Installer allows it, this is only possible during custom actions scheduled for rollback. However rollback only applies to the deferred script, so it's only available for actions scheduled between InstallInitialize and InstallFinalize. If an immediate-mode action outside this scheduling window causes the installation to abort, rollback does not apply.
Assuming you're using a C++ or InstallScript action, you can find out if rollback is enabled, and if you're in rollback, with calls to MsiGetMode - using MSIRUNMODE_ROLLBACKENABLED or MSIRUNMODE_ROLLBACK respectively.
I want perform custom action after files are copy in destination folder.
In custom action i run copied script file so give me error file not found.
<CustomAction Id="RunDBScript"
BinaryKey="CA"
DllEntry="RunDBScript"
Execute=" immediate"
Return="check" />
<Custom Action="RunDBScript" After="InstallFiles">
<![CDATA[NOT Installed]]>
</Custom>
this custom action give an error file/directory not found. so this action call before file copy.
so, how to call custom action after file copy?
I am not understand why this custom action call before InstallFiles even though i am specified After="InstallFiles".
Move your custom action after InstallFinalize. This is the only place in InstallExecuteSequence where Immediate actions can be executed after installing the product files.
When you use deferred custom actions, you must access values through session.CustomActionData["propertyname"].
Session dictionary values can be read only by immediate custom actions, where the execution script is being written.
The deferred custom actions are executed at script running time, so the project properties are no longer available.
To make use of it, you must implement a double custom action in order to provide the desired properties for the real custom action.
Follow the bellow example:
<CustomAction Id="CustomActionID_Data" Property="CustomActionID" Value="INSTALLDIR=[INSTALLDIR];OTHERPROPERTY=[OTHERPRPJECTPROPERTY]"></CustomAction>
<CustomAction Id="CustomActionID" BinaryKey="FILEBINARYID" DllEntry="METHODNAMEATCUSTOMACTION" Execute="deferred"></CustomAction>
At this example, you need to call at InstallExecutionSequence the custom action "_Data" and after call the real one, so the first "_Data" will se the desired properties. Then you can access those properties on your code using session.CustomActionData[""].
Just complementing, bellow is an example of how to call the custom actions at InstallExecuteSequence.
<Custom Action="CustomActionID_Data" After="InstallFiles">NOT (REMOVE="ALL")</Custom>
<Custom Action="CustomActionID" After="CustomActionID_Data">NOT (REMOVE="ALL")</Custom>
I have the following CustomAction in my project:
<CustomAction Id="InstallDriver"
Return="check"
Execute="deferred"
Impersonate="no"
FileKey="FileDriverInst"
ExeCommand="-install" />
<InstallExecuteSequence>
<Custom Action="InstallDriver" Before="InstallServices" />
</InstallExecuteSequence>
The program that installs the driver produces useful return codes, for example if the installation failed because the system needs to be restarted following a previous driver uninstall.
Currently if anything other than success is returned, I get a dialog saying 'A program run as part of the setup did not finish as expected.' and the installation fails. This is not optimal.
How can I get and handle return codes?
Windows Installer doesn't support handling custom action return values.
For an EXE custom action a non-zero return value is interpreted as an error and the installation stops. Only a win32 DLL or VBScript custom action can change the installation behavior through its return code, but it's still very limited.
If you want to reboot the machine after install, you can set the REBOOT property.
Added as an "answer" by request:
Your whole design is not optimal. It's out of process to Windows Installer and isn't declarative. There are better patterns for installing drivers.
That's simply the way MSI handles EXE calls. You'd have to write your own custom actions to wrap the EXE call and then interpret the failure reason. To me this just adds yet another failure point.
You can't get a return code from a CustomAction, but in a round about way you can set what that return code would be on a property. That might as well be the same thing as getting the return code.
You have to get it within the script/dll your custom action is performing. Otherwise, the return code only shows up in the log.
For example, if you have property like
<Property="MyCode" Secure="yes">
Then within VBScript (or Jscript) you can get the value of that property like this:
VBScript
Session.Property("MyCode")
Initially, it is null. You can set it in VBScript like this:
If someCondition = 4 Then
Session.Property("MyCode") = "4" // For a return code of 4
End If
Once back in your WiX .wxs file, if you look at the value of your property, it is now 4. You could even use it in CDATA tags.
For example, only spawn a dialog if MyCode is equal to 4.
<Publish Dialog="SpawnDialog" ...><![CDATA[ MyCode = 4 ]]></Publish>