1

In the past I've written all my custom actions in VBScript, because my understanding is that this (and JScript) is the only type of custom action which does not require additional prerequisites on the target system.

However, writing VBScript is a pain, and now I also encountered a problem which apparently cannot be solved in VBScript (see Currupted file in non-english locale (encoding problem?)).

So I'm considering using a C# custom action instead. But I don't want to introduce additional prerequisites just for the custom action (note that the application I'm installing does not use the .NET Framework).

This list shows which Windows version includes which .NET Framework version. Assuming that newer .NET Framework versions are backwards compatible, it looks like a .NET Framework 2.0 custom action should run on virtually any Windows version (except for XP, which I don't care about) out of the box. But then on this site it says

In addition, if your app targets version 2.0, 3.0, or 3.5, your users may be required to enable the .NET Framework 3.5 on a Windows 8, Windows 8.1, or Windows 10 computer before they can run your app.

So it looks like the assumption that newer .NET Framework versions are backwards compatible is not correct...

The WiX custom action project created a CustomAction.config file with the following settings:

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

So here are a few questions:

  1. Can I assume that a .NET Framework 2.0 custom action with the above config runs on any Windows (except for XP)? Or does .NET Framework 3.5 need to be enabled on newer versions of Windows despite the fact that the config file states 4.0 as a supported runtime?
  2. What's generally speaking the best way to create a custom action (not VBScript or JScript) without introducing any additional prerequisites? (I was considering a "C++ Custom Action Project for WiX v3", but it looks like this creates a managed C++ project, so the same questions around .NET Framework arise).

Update:

I tested this .NET Framework 2.0 custom action in a fresh Windows Server 2008 R2 and in a fresh Windows 10 VM. The custom action ran without needing to install the .NET Framework manually. So based on this little test it looks like compatibility of such a custom action is quite good.

Robert Hegner
  • 9,014
  • 7
  • 62
  • 98
  • Generally speaking, C++ custom actions with statically linked runtime have the least dependencies. Don't need the WiX project wizard, just create a Win32 DLL project. [Here](http://bonemanblog.blogspot.com/2005/11/custom-action-tutorial-part-ii.html) is a step-by-step tutorial. It's for VS2003 but should be applicable for newer VS versions aswell. – zett42 Jul 29 '19 at 09:31
  • I agree, statically linked C++ is best. It is the only thing that is good enough for global distribution IMHO. Are you targeting this package for corporate use or global distribution to any PC anywhere? Seems the latter, but just wondering. – Stein Åsmul Jul 29 '19 at 15:54
  • I decided to go with the C# custom action targeting .NET Framework 2.0, as it turns out that it works on a wide range of operating systems without the need to manually install the framework (see my updated). Writing the custom action in C++ would be safer with regards to compatibility, but it is also more painful to write it. – Robert Hegner Jul 30 '19 at 11:58
  • Yes, contrary to what I would normally recommend (I am a big proponent of minimal dependencies), but when it comes to Unicode, localization and globalization VBScript just does not function reliably. I believe - without being and expert - that the .NET world is way better with localization issues. What I would actually do would be to try to eliminate the custom action and use your application to do the work on launch - which is not always possible. [Propaganda against custom actions](https://stackoverflow.com/a/46179779/129130). Whatever works, whenever it works, with acceptable risk? – Stein Åsmul Jul 30 '19 at 12:35
  • Added an answer below to link to a couple of resources on this topic. – Stein Åsmul Oct 28 '20 at 18:36

1 Answers1

0

There are some issues with .NET custom actions. I have this old answer - that I haven't reviewed in a while. I remember I read it once thinking "I must have lost my mind that day". It is the list towards the end of the answer that mentions a few managed code problems (quickly: 1) too many dependencies, 2) CLR version load behavior issues (up to date?), 3) GAC dependencies, 4) lack of minimal dependencies and uninstall issues, 5) Broken or unavailable .NET runtime, etc...). I am not an expert on this topic.

It seems to get better over time to use .NET because the runtime is now part of the OS. You can lock a setup so it won't install on downstream OS by means of Launch Conditions. And there aren't that many CLR versions - just 2 and 4 basically?

Here are two answers on using C++ and C# / .NET respectively for custom actions:

Remember the propaganda against custom actions. They are error prone. Very.

Links:

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164