How to execute conditional custom action on install and modify only?
Asked Answered
B

1

2

I have a installer which is working fine. I want to run custom action only in install and modify only. Here is my custom action:

<Custom Action="UpdateAPMDBAPasswordAndStoreInRegistry" After="InstallFinalize"><![CDATA[&BaseModel = 3 OR &FeaturePostMaster = 3]]></Custom>

The above custom action is not running when modify the the installer. It runs only when install the installer. After googled, i did this but it is also not working:

<Custom Action="UpdateAPMDBAPasswordAndStoreInRegistry" After="InstallFinalize"><![CDATA[(&BaseModel = 3 OR &FeaturePostMaster = 3) AND (NOT Installed OR MaintenanceMode="Modify")]]></Custom>

It also run only in install mode. What i am doing wrong?

Balancer answered 17/9, 2018 at 14:54 Comment(0)
D
4

InstallFinalize: Do you write to HKCU or HKLM? Anything sequenced after InstallFinalize will not run elevated in a managed environment and will hence fail during installation if you try to write to HKLM(unless you change the ACL for the key you write to - or you kick the MSI off from a cmd.exe that is elevated already - not recommended, the package is flawed).

MaintenanceMode: That condition looks like it is Installshield-specific: NOT Installed OR MaintenanceMode="Modify". I think Installshield itself sets that MaintenanceMode property in a proprietary fashion. Hence it is not available in WiX at all.

Testing Conditions: Conditions can be hard to test and you need to do real-world testing in many installation modes (install, uninstall, repair, modify, patch, major upgrade, self-repair, etc...) to be sure they fit your particular case and work as expected. A typical scenario where people are surprised at conditioning is major upgrades - the uninstall of your old version and the installation of the new version - it tends to reveal unexpected problems with conditions in my experience. Often due to the complex sequencing issues and the fact that during such an upgrade both the old setup's uninstall sequence and the new setup's install sequence run. Hence erronously conditioned custom actions can run several times during the major upgrade process and cause a real mess. Please read this answer for more: Run Wix Custom action only during uninstall and not during Major upgrade and this short version.

Testing Tip: To implement a quick major upgrade you need to change the product code and bump up one of the first 3 digits of the version. And you need to have the MajorUpgrade element in there. You can set the product code to auto-generate by setting it to * (I prefer to change it manually). Compile an MSI, suffix it with "_Version1" then do the updates mentioned and compile "_Version2". Run upgrade sequence. You should also point to the updated files for version 2 by changing the source path, but you can roll without it to test conditions.

Modify: For your case, there is a cheat sheet from the Installshield guys suggesting the following condition in their "MSI Condition Cheat Sheet":

  • Installed AND NOT REINSTALL AND NOT REMOVE~="ALL"
  • The above condition should enable the custom action to run in modify operations only. If you change it a little it should work for install and modify only:
  • NOT Installed OR ((Installed AND NOT REINSTALL) AND NOT REMOVE~="ALL")

I will have to run an extra check on that last condition tomorrow, but I just post this so you can get testing yourself. I took out PATCH, but maybe I should add it back to cover major upgrade patches. Will you be delivering patches?


Quick Mockup for Light-Weight Condition Testing:

The VBScript:

Note! Make sure the VBScript file is in UTF8 or ANSI. Unicode will not work. Maybe create it in Notepad rather than Visual Studio. I have seen issues when creating the VBScript file as a WiX text file that I then rename to *.vbs format. Don't do that.

MsgBox "I run, therefore I am conditioned and sequenced"

WiX Markup, Custom Action:

<Binary Id='SayHelloMsgBox.vbs' SourceFile='SayHelloMsgBox.vbs' />
<CustomAction Id='SayHelloMsgBox.vbs' VBScriptCall='' BinaryKey='SayHelloMsgBox.vbs' Execute='immediate' Return='ignore' />

WiX Markup, Sequencing & Conditioning:

<InstallExecuteSequence>
   <Custom Action='SayHelloMsgBox.vbs' After='InstallInitialize'>NOT Installed OR ((Installed AND NOT REINSTALL) AND NOT REMOVE~="ALL")</Custom>
</InstallExecuteSequence>

Writing to Log: You can write to the MSI log from VBScript as described in this article: MSI Tip: Writing to the Log File from a Custom Action.


Update: You can eliminate a separate VBScript file for the condition debugging using this approach.

Deguzman answered 18/9, 2018 at 1:48 Comment(13)
Asmul, thanks for reply. This is HKLM. I have put NOT Installed OR ((Installed AND NOT REINSTALL) AND NOT REMOVE~="ALL") condition and the CA runs in install but run in modify only when i change something in installer features. If i change database or change nothing it is not running. I want to run CA in any case of MODIFY even if user change nothing in installer feature. Also i have to deliver patches also.Balancer
NOT REMOVE~="ALL" resolve my case. It runs in all cases except in uninstallation. Thanks for sharing cheat sheet and thanks helping again.Balancer
Do you run this custom action in the UI sequence? (I don't think you do seeing as you mention InstallFinalize, but just want to verify since conditions can be slightly different in each sequence by the looks of things). What WiX dialog set are you using? Look for UIRef elements. I use <UIRef Id="WixUI_Mondo" />. In my tester that condition you mention in your first comment makes the custom action run on fresh install and modify only (even without any feature modifications), but I don't doubt your results - which is why I want some more details if you don't mind.Thug
Oh, I assume you have appended it to the existing condition you have with the feature conditions &BaseModel = 3 OR &FeaturePostMaster = 3. I didn't see that. I would assume that means you have to change the feature state for the condition to be true, yes. Haven't tested yet.Thug
Conditions are hard to debug. I have some constructs that can help if you need more debugging. It involves message boxes and scripting to show when a condition is valid, but you might have this already.Thug
Is there any way to debug conditions or check it is valid or not?Balancer
Yes, you can use the Session.EvaluateCondition("ConditionHere") method in a script or in some other custom action to run at different sequence positions to get proof positive whether the condition is valid or not (at that time and sequence). You can also simply make a custom action that shows a message box with a recognizable message and condition it with the condition you want to test, and see when it shows up and not.Thug
Let us continue this discussion in chat.Thug
learn.microsoft.com/en-us/windows/desktop/Msi/… This link is helpfulBalancer
i need to ask one thing.Balancer
You can create a new question? It looks like the chat room was auto-deleted for inactivity.Thug
yes. I am working on what i want to ask. If face any issue then will let you know with new questionBalancer
InstallShield's cheat sheet linked to by @SteinÅsmul is gone. Here's another cheat sheet that could be useful: files.cnblogs.com/dulvyizhihua/installshield_conditions.pdf.Miterwort

© 2022 - 2024 — McMap. All rights reserved.