1

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?

umer
  • 2,634
  • 6
  • 27
  • 51

1 Answers1

2

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.

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.

Stein Åsmul
  • 34,628
  • 23
  • 78
  • 140
  • 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. – umer Sep 18 '18 at 05:48
  • NOT REMOVE~="ALL" resolve my case. It runs in all cases except in uninstallation. Thanks for sharing cheat sheet and thanks helping again. – umer Sep 18 '18 at 06:27
  • 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 ``. 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. – Stein Åsmul Sep 18 '18 at 07:55
  • 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. – Stein Åsmul Sep 18 '18 at 07:59
  • 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. – Stein Åsmul Sep 18 '18 at 11:09
  • Is there any way to debug conditions or check it is valid or not? – umer Sep 18 '18 at 11:19
  • 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. – Stein Åsmul Sep 18 '18 at 11:26
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/180264/discussion-between-stein-asmul-and-umer). – Stein Åsmul Sep 18 '18 at 11:34
  • https://docs.microsoft.com/en-us/windows/desktop/Msi/examples-of-conditional-statement-syntax This link is helpful – umer Oct 11 '18 at 09:22
  • i need to ask one thing. – umer Oct 12 '18 at 08:19
  • You can create a new question? It looks like the chat room was auto-deleted for inactivity. – Stein Åsmul Oct 12 '18 at 09:48
  • yes. I am working on what i want to ask. If face any issue then will let you know with new question – umer Oct 12 '18 at 09:49