Simple WiX Custom Action in Custom UI Ends Prematurely with Windows 7

Question

My WiX installer UI is getting error while using the Custom Action. Interesting part is, the installer is working fine in Windows 10 but while launching it on Windows 7, installer is getting interrupted.

From the installer logs, the error code is displayed 2896. Googling further the error code, pointed me that it could be the mismatch of .net framework version. So I modified my CustomAction.config as follows :

<startup useLegacyV2RuntimeActivationPolicy="true">
        <supportedRuntime version="v4.0" />
        <supportedRuntime version="v3.0" />
        <supportedRuntime version="v3.5" />
        <supportedRuntime version="v2.0.50727"/>

</startup>

I verified the installed version through using following command :

reg query "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP"

is there something else am I missing here ?

EDIT: Here is the custom action code for your reference :

namespace ValidateIP
{
    public class CustomActions
    {
        [CustomAction]
        public static ActionResult ValidateIP(Session session)
        {
            session.Log("Begin ValidateIP");
            if (string.IsNullOrEmpty(session["IPVAL"]))
            {
                session["VALIDIP"] = "0";
            }
            else
            {
                session["VALIDIP"] = "1";
            }
            return ActionResult.Success;
        }
    }
}

Bulk

Maybe try to do verbose logging with extra debugging information and direct write without buffering (to prevent loss of log buffer due to crashes): msiexec.exe /i C:\Path\Your.msi /L*vx! C:\Your.log and see if you get more information about the runtime error. – Adjuvant

May be your custom action is .Net custom action which was built targeting specific .Net framework version which is may not be available on target machine where installer is being run. – Shaina

@PankajKapare can you please check my comment for Stein's answer. – Bulk

@Rahul:Well, it doesn't matter how basic and trivial your custom action is. If custom action dll was built for .Net 4.7 and if you have just .Net 3.5 on target machine then its not going to work. – Shaina

@PankajKapare correct, but I am also just started with wix, so don't have complete knowledge about it. btw I have updated the question with my code, can you please check. – Bulk

Answer 1

So it turns out that although I was using the different .Net version in my CustomAction.config file, but in Custom Action project the targeted .Net version was 4.5. So it was superseding the config properties. Once I reduced it to 3.5, it started working. Thanks everyone for all the suggestion.

Bulk

A very disputed opinion of mine: I am very skeptical to managed code CAs for this and many other reasons (towards the bottom, maybe a bit over the top). Hesitatingly I recommend VBScript for read-only GUI-sequence custom actions contrary to the advice of many experts in the field. Windows Installer hosts the ActiveScripting runtime - it will run (barring serious malware and system corruption). There are many good reasons to avoid (complex) VBScripts. – Adjuvant

What experts know, is that once you are using VBScript for something simple, you will often experience changed requirements that make your simple read-only, GUI-sequence only VBScript a real nightmare as it morphs into the evil thing we know it tends to become - as it is changed to make system changes (no longer read-only), and triggers failed installs as you try and fail to instantitate COM servers and write to unsafe locations blocked by security software. And the big problems: the overall lack of debugability for script code - and the lacking language features strike you with a vengeance. – Adjuvant

And to finish off: in the future all custom actions will probably be managed - once we get the worst pitfalls sorted. Then we might see better runtime security as well than what is available with native code? For now VBScript wins over managed code in a "battle of fools" in my view for two core reasons: 1) runtime dependencies / reliability (recent OS versions actively fix broken ActiveScripting and COM components), 2) scripts allow full embedded source in your MSI (you know what code-base is in your setup - just extract it - no source control issues and chaos because the source is missing). – Adjuvant

Answer 2

I am not an expert on managed code custom action, Chris Painter is the man for this, but let me check a couple of things:

• Does this custom action require admin rights?
• If it does, is it configured as a deferred mode custom action run in system context?
• In what sequence is the custom action running? GUI? Execute? Both?
• What is the custom action actually doing?
• What .NET classes and .NET features and Widows features does the custom action depend on? (for all we know you could be instantiating COM servers for example)

---

Verbose, debug, logging: See installsite.org on logging. From that content, I would try:

msiexec.exe /i C:\Path\Your.msi /L*vx! C:\Your.log

This is full, verbose logging (*v) with extra debugging information (x) and continuous logging (!) (as opposed to writing the log in batches). The latter makes the install much slower, but assures that no log-buffer is lost due to crashes.

---

Some Links (for safekeeping):

• Error 2896 using a WiX C#/.NET 4 custom action

Longlegged

It is very basic action, where I will take a value in edit text in custom dialog, and when user press the next, it checks the value for null. It is part of GUI sequence. And I really doubt it depends on any .Net feature. And I tried debugging the log with verbose and even that doesn't give me any additional information. – Bulk

@Bulk You can't get logs from an action initiated through DoAction events without some extra work. msdn.microsoft.com/en-us/library/aa368322(VS.85).aspx There are some ways to do logging but it is a bit more involved. You could potentially launch a message box and attach a debugger to that to debug your custom action. – Annmaria

Yes, I always refer to this article by Robert Dickau for custom action logging. – Adjuvant