Wix - During install/upgrade a Custom Action's conditions resolve to False when they shouldn't

Question

The Setup

So I have a Custom Action in my InstallExecuteSequence that looks like this:

    <Custom Action="UpdateConfigFile" After="InstallFinalize">NOT Installed OR Upgrading</Custom>    

Where Upgrading is defined to:

        <SetProperty After="SetFirstInstall" Id="Upgrading" Value="true">
         WIX_UPGRADE_DETECTED AND NOT (REMOVE="ALL")
        </SetProperty>

The Custom Action updates a web.config file with a value that is passed into the installer via a Property. It is a VB.Net function.

The Issue I'm Running Into

This Custom Action has always executed in many of our installers. But for a certain environment that we have in development, the conditions for it resolve to False on a install/upgrade scenario. It says "(condition is false)" in the MSI log.

The environment is used for development purposes such as testing the product after installed/updated.

What I'm Trying to Accomplish

I would like this to be resolved so that this environment can install our product successfully.

What I've Done So Far

I've installed the same installer to different Operating Systems such as Windows 10, 2012 R2, and 2016. The installer works just fine since the Custom Action runs as expected.

The troublesome environment is a Windows Server 2012 R2 machine. Which makes me even more confused.

I did some digging in and was only able to find this link: (https://blogs.msdn.microsoft.com/heaths/2006/07/11/why-a-custom-action-may-not-run/#comments)

From the link's suggestion, I think it is really odd if a dependency was missing because the same installer works on other machines.

So I'm pretty stumped at this point. Any help or direction would be very much appreciated. If I'm not being clear enough, feel free to ask for more clarification. Please and thank you.

Answer 1

Just some comments to get going, this isn't a real answer:

• First things first: in order to be passed properly to deferred mode (InstallExecuteSequence) properties should be UPPERCASE (public properties) and they should be listed in the SecureCustomProperties delimited list of "safe properties" to pass to deferred mode.
• Other than uppercasing it, I wouldn't set a property called Upgrading like that, I would rather use the "raw" conditions for the custom action in deferred mode (InstallExecuteSequence).
• Here is a cheat sheet of common conditions from Flexera (makers of Installshield): Common MSI Conditions Cheat Sheet. And here is a direct link to the PDF.
• You can have a look at this old post: How to add a WiX custom action that happens only on uninstall (via MSI)?. I have never had the time to test all those conditions, but at face value it looks correct.
• Some notes about the special property UPGRADINGPRODUCTCODE.

---

UPGRADE:

Questions:

• That Windows Server 2012 R2 machine - is there anything special about it? Is it tightened for security? What is its task or purpose on the network?

• What is the actual implementation of UpdateConfigFile - is it a script, a compiled DLL written in C++, a managed DLL written in a .NET language, or something else? Maybe an EXE file?

• Does any of this sound familiar: Installer fails on Windows Server 2012 R2

• Did you verify that the correct version of the .NET framework is installed on this problem server? Does the function run interactively? Try running that VB.NET function interactively on that computer via a test harness EXE if it is a DLL function. Or just run it straight is it is an EXE file outright.

Answer 2

The issue is likely to be that you are scheduled after InstallFinalize (which is not good, see later) because the Upgrading property is not public (not uppercase). If you change the condition to WIX_UPGRADE_DETECTED AND NOT (REMOVE="ALL") it should work, assuming:

1. WIX_UPGRADE_DETECTED is the actual property associated with the major upgrade, such as from the major uypgrade element.

2. WIX_UPGRADE_DETECTED is in SecureCustomProperies.

Actions after InstallFinalize are generally not recommended because if they fail (in your case screw up the config file) then there is not much that can be done (such as roll back to a correct config file). It's effectively after the install, so it's also easier to do the config changes in the app when the upgraded version runs for the first time.

Answer 3

After helping the team responsible for the environment, we found out that it was a certain scenario that was causing this issue. Digging deep into the MSI log further, we found that a previous Custom Action running, also after InstallFinalize, was returning a Failure Action Result. Since that happened, the following Custom Actions such as my UpdateConfigFile Custom Action, don't execute. Resulting in the "(condition is false)" entry in the log.

Once we figured that out, I was able to reproduce it on my local environment.

Since these Custom Actions are after InstallFinalize, I thought that those Custom Actions would still run if one failed because we're past the point of the installer being able to do a Rollback. But I was wrong and now I know.

Thanks for everyone helping me out in trying to figure out this issue. I was getting worried that I was going to try to figure this out for days and start pulling my hair out. XD