1

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.

Jaime Ulises Alvarez
  • 23
  • 5
  • 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. – Stein Åsmul Dec 18 '17 at 23:05
  • I am adding too many comments, but it may be that what you do in your custom actions can be done by MSI itself with built-in features, or by a built-in feature in WiX. These are way better for reliability and maintenance alike. Prefering custom actions is one of the common mistakes people make with MSI. [**Some common MSI problems are discussed here**](https://stackoverflow.com/questions/45840086/how-do-i-avoid-common-design-flaws-in-my-wix-msi-deployment-solution/45840087#45840087). If you roll with custom actions, you must make them deferred and elevated to avoid deployment problems. – Stein Åsmul Dec 20 '17 at 13:51

3 Answers3

2

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

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.

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
  • Gotcha, I wasn't the one who made the 'Upgrading' Property. But we have been using it and has worked for us. That's a useful cheat sheet, nice find. I'll share this with my teammates. I do feel like the issue I'm running into could be environment specific. So at least I'd like to know more of how those conditions are resolved. With that knowledge perhaps it will help more in narrowing down the problem. Thanks for commenting! – Jaime Ulises Alvarez Dec 18 '17 at 22:14
  • Please do thorough testing when picking conditions off that cheat sheet. I haven't actively used it. But it should be a good start. The linked stackoverflow answer with the condition table is good, but there are some snags there as well. For example REMOVE can be set in more cases than what is listed in the table I believe. Conditions are complicated - try to keep them as simple as possible. – Stein Åsmul Dec 18 '17 at 22:17
  • I added a few questions for clarification. Maybe update your question with more details rather than us adding too many comments? – Stein Åsmul Dec 18 '17 at 22:55
  • I added some more details to the extent that I know. – Jaime Ulises Alvarez Dec 18 '17 at 23:04
0

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.

PhilDW
  • 20,260
  • 1
  • 18
  • 28
  • Digging closer I did see the WIX_UPGRADE_DETECTED value being correct and from seeing that I decided to see if there was a separate issue. I've posted my answer on what the problem was. Yeah I'm not happy either with some of our Custom Actions running after InstallFinalize since we can't rollback. The reason it's there is because we have some code in the installer that is dependent on the files the installer is going to deploy. I'm not sure if there is a way to interact with those files before InstallFinalize. If it's possible I would love to know so I can share that information. – Jaime Ulises Alvarez Dec 19 '17 at 20:31
0

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

Jaime Ulises Alvarez
  • 23
  • 5
  • Do these custom actions after InstallFinalize change the system? If so you could see further problems besides what you have already discovered. The actions may be skipped entirely when your setup is run silently via a deployment system such as SCCM, and they may trigger access errors since they don't run in the elevated part of the setup sequence. – Stein Åsmul Dec 19 '17 at 22:29
  • Please read this post, and the one immediately below with a tutorial on **deferred mode custom actions**: http://forum.installsite.net/index.php?showtopic=3078#entry42232. **Immediate mode custom actions** must not change the system (they don't run elevated, but can succeed if you run as an admin in interactive GUI install mode - but they fail immediately otherwise), deferred mode custom actions can run elevated and change the system - they are quite involved to deal with as explained in the post. Another link for reference: http://forum.installsite.net/index.php?showtopic=15649#entry44093 – Stein Åsmul Dec 19 '17 at 22:52
  • I updated the linked forum answers a little for 2017. Please do read them Jaime, to save yourself and your team some trouble. You will need a couple of days to do this right, it is worth the time. And yes, some MSI designs border on anti-patterns as I mention towards the bottom of [**this answer**](https://stackoverflow.com/a/1055861/129130) (do read the section on anti-patterns and MSI corporate benefits towards the bottom for a quick understanding of why MSI is still good, despite its flaws). Developers see the flaws, sysadmins see flaws and some massive benefits as well. – Stein Åsmul Dec 20 '17 at 09:51
  • Wow thanks @SteinÅsmul, I will take a good read on these and share it with my team. Thanks again for your help! Have an awesome holiday! – Jaime Ulises Alvarez Dec 20 '17 at 23:08
  • Same to you sir, and good luck with your efforts to get your package sorted. – Stein Åsmul Dec 20 '17 at 23:37