1

During the installation I need to customize some configuration files which is basically to search and replace certain keywords given as Properties to the msi intaller. The custom action looks like this:

 <CustomAction Id="SetApplicationProperties"
    Directory="CONFIG.DIR"
    ExeCommand="powershell -NoProfile -NonInteractive -ExecutionPolicy Bypass -Command &quot;cat application.properties.template | % { $_ -replace 'SERVERNAME','[SERVERNAME]' } > application.properties.customer&quot; "
    Execute="deferred"
    Impersonate="no"
  />

However I only get an empty "application.properties.customer" file. no error/warning in installer logfile. I tried various combination of quoting the strings but w/o success. Reducing the command to:

ExeCommand='powershell -NoProfile -NonInteractive -ExecutionPolicy Bypass -Command "cat application.properties.template  > application.properties.test" '

works, so it seems to be a problem with the quoting of the "-replace..." statement.

Has anyone any sugestions how properly set the quotes for the installer?

Sven Keller
  • 491
  • 1
  • 5
  • 11

2 Answers2

1

Meanwhile I found a solution for the issue myself after some trial and error I figured out that the '{' and '}' were eliminated during "transfer" from project to execution. I've found this link helpful as starting point for further experiments. The result is that [\{] VALUE [\}] can be used to "escape" the parenthesis. Working code now looks like:

  ExeCommand="powershell -NoLogo -NoProfile -NonInteractive -InputFormat None -ExecutionPolicy Bypass -Command &quot;cat application.properties.template | % [\{] $_ -replace '&lt;SERVERNAME&gt;','[SERVERNAME]' [\}] > application.properties.customer 2>&amp;1 &quot; "
Sven Keller
  • 491
  • 1
  • 5
  • 11
0

PowerShell CAs Considered Harmful: Using PowerShell for custom actions is a very bad runtime requirement to trigger. It is both a script AND it is managed code - both are problematic in its own right. Scripts are generally hard to debug and can trigger anti-virus lockups, and managed code depends on the .NET runtime and has a number of well-known technical pitfalls (versioning issues, load behavior of CLR version, there are many more issues...). Avoid PowerShell custom actions if you can.

XML Updates: Is this an XML file? If so, maybe you can try WiX's own XML update features? Maybe see this answer: Added new application setting to app.config but MSI won't install it (doesn't overwrite).

JSON: If it is JSON let me lob you just a link, not used by me so far. All I found in my bookmarks. Pillaging github.com is a common approach for me. Just do a search.

INI: Maybe it is even in INI format? If so I have no samples for you. Commercial tools InstallShield and Advanced Installer allow you to retrieve values from INI files. MSI's built-in features are probably too quirky to do so (Encoding issues, limited feature set). I am not sure if WiX has extended support to retrieve INI file values.

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
  • thanks for your valuable comments. You're right it might be problematic to use scripts this way. The simplicity of the way to get the work done with a script (compared to a separate C# or whatever project) was the reason to do so. The file format is (currently) a custom format, which also might change to json or xml standard file. – Sven Keller Dec 04 '18 at 10:38
  • OK, please be aware that you can debug C# and C++ code by [attaching the Visual Studio debugger](https://stackoverflow.com/a/52880033/129130) ([secondary link](https://stackoverflow.com/a/51940598/129130)). Once you do that you have an easier ride than with scripts. You can really debug quickly and sort out most issues. I use scripts for debugging, and for environments where I don't have proper source control and don't want to compile - as you say. Often when many people collaborate on an internal corporate application. All depends on what makes sense, but scripts are challenging to debug. – Stein Åsmul Dec 04 '18 at 11:37