Wix Custom Action Error in .NET3.5

Question

I have created an installation package (msi) with Wix and Custom Actions. The installation works fine on systems with .NET4 installed, however on clean systems (WIN7 .NET3.5) it fails with the bellow error. I narrowed the wxs package and it seems that if I remove the reference to CustomActions the msi installs (but without registry alterations). CustomActions are entering new values to Registry based on user PC config. Again the same project works flawlesly on .NET4 PCs. The Target framework is set everywhere to .NET3.5. Any ideas?

=== Logging stopped: 7/13/2014  14:23:19 ===
MSI (c) (00:F4) [14:23:19:249]: Note: 1: 1708 
MSI (c) (00:F4) [14:23:19:249]: Note: 1: 2205 2:  3: Error 
MSI (c) (00:F4) [14:23:19:267]: Note: 1: 2228 2:  3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 1708 
MSI (c) (00:F4) [14:23:19:267]: Note: 1: 2205 2:  3: Error 
MSI (c) (00:F4) [14:23:19:267]: Note: 1: 2228 2:  3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 1709 
MSI (c) (00:F4) [14:23:19:267]: Product: MyProject -- Installation failed.

MSI (c) (00:F4) [14:23:19:267]: Windows Installer installed the product. Product Name: MyProject . Product Version: 1.0.1. Product Language: 1033. Manufacturer: Me. Installation success or error status: 1603.

Answer 1

Its rather strange fix but, all I had to do is to add the bellow snippet. I thank you all for your support.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <startup useLegacyV2RuntimeActivationPolicy="true">
    <supportedRuntime version="v4.0" />
    <supportedRuntime version="v2.0.50727" />
  </startup>
</configuration>

Answer 2

I'll try to provide an answer though I am not fully up to speed on this particular issue. This obviously doesn't help if your application requires .NET 4, but did you try to compile your code to target the .NET 2.0 framework instead of .NET 4? Most computers should be able to run 2.0 code, unless that framework is explicitly locked for use - which can be the case in some companies.

Runtime restrictions like that makes me prefer native C++ code (or Installscript which is also native in later versions of Installshield) for serious setups for widespread use.

Emulated custom action code (.NET code or active scripting such as VBScript effectively) is fine for in-house stuff though - it even yields transparency for the setup as to what it is up to which is a key corporate benefit of MSI .

Other than targetting .NET 2.0 you can also check that the right version of the .NET framework is available and abort the setup or install it as a prerequisite via Wix's Burn feature .

Finally, and this is actually my preferred solution, you can have the application itself update the registry with the required settings and leave them out of your setup. This allows more flexibility and error handling. It all depends what kind of settings you are adding. HKLM settings must generally be added by your setup.

Answer 3

1. you will have far less trouble by doing it using vbscript custom actions, if possible.
2. the best practice is to use custom actions only when it's absolutely can't be done by native Installer's ways. From what you described, "CustomActions are entering new values to Registry based on user PC config", it looks like you can accomplish it by creating system search for whatever in PC config matters, then condition the components with registry values on the properties returned by system search.