WiX Custom Bootstrapper Application and .NET 4.5

Question

I am having difficulties getting a WiX Custom Bootstrapper Application that targets .NET 4.5 to work.

I have the following line in my Bundle.wxs.

<PackageGroupRef Id="NetFx45Web" />

My BootstrapperCore.config is as follows.

<configuration>
    <configSections>
        <sectionGroup name="wix.bootstrapper" type="Microsoft.Tools.WindowsInstallerXml.Bootstrapper.BootstrapperSectionGroup, BootstrapperCore">
            <section name="host" type="Microsoft.Tools.WindowsInstallerXml.Bootstrapper.HostSection, BootstrapperCore" />
        </sectionGroup>
    </configSections>
    <startup useLegacyV2RuntimeActivationPolicy="true">
        <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
    </startup>
    <wix.bootstrapper>
        <host assemblyName="FSCustomBA" />
    </wix.bootstrapper>
</configuration>

I have tried multiple variations of this.

For example, I have also tried the following.

<host assemblyName="FSCustomBA">
    <supportedFramework version="v4\Full" />
    <supportedFramework version="v4\Client" />
</host>

And the following.

<host assemblyName="FSCustomBA">
    <supportedFramework version="v4.5\Full" />
    <supportedFramework version="v4.5\Client" />
</host>

And the following.

<host assemblyName="FSCustomBA">
    <supportedFramework version="v4.5" />
</host>

And the following.

<host assemblyName="FSCustomBA">
    <supportedFramework version="v4.5\Full" />
</host>

And the following.

<host assemblyName="FSCustomBA">
    <supportedFramework version="v4.5\Client" />
</host>

No matter what I have tried, when I run my setup package on a system that does not have .NET 4.5 installed, I am prompted to install .NET 4.5. Once I press the Agree and Install button, the setup package crashes. When I attempt to run the setup package again, it hangs before it displays the buttons. It hangs even after I reboot. I need to restore my system from the system image before it will run again.

Can anyone tell me what I am doing wrong?

I am using WiX 3.10.

Thus far my only clue as to what is going on is the following line in the resulting log files.

[1A14:1778][2016-06-28T10:01:17]i000: The prerequisites were already installed. The bootstrapper application will not be reloaded to prevent an infinite loop.

This is mentioned in another question here on Stack Overflow, Prerequisite bootstrapper application fails to install .NET 4.5. One of the answers to this question suggests that the answer is to set the sku value in the supportedRuntime element of the BootstrapperCore.config file. However, I have done this. Something else is going on.

Nelsonnema

I have a clue as to what is going on. I followed the example of the WixBA and TestBA applications that are part of WiX, which is to name the BootstrapperCore.config file after the pattern ${ProjectName}.BootstrapperCore.config. What I did not realize is that when this file is included in the bundle via the Payload element you need to use the Name attribute to rename it to BootstrapperCore.config. – Nelsonnema

Now I am getting another error.: "0x80131040 : The located assembly's manifest definition does not match the assembly reference." – Nelsonnema

I resolved the error "0x80131040 : The located assembly's manifest definition does not match the assembly reference" by setting the SuppressSignatureVerification attribute to yes for the Payload element associated with my Custom BA. I think this is only necessary because I am using the test (self-signed) certificate instead of a trusted certificate. – Nelsonnema

Answer 1

I am posting an answer to my own question in the hopes that it will benefit others who encounter similar problems.

It turns out that the problem was not in the contents of my BootstrapperCore.config file, but in the name of my BootstrapperCore.config file. That is, the final contents of my BootstrapperCore.config file turned out to be exactly what I indicated in my question, which is as follows.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <configSections>
        <sectionGroup name="wix.bootstrapper" type="Microsoft.Tools.WindowsInstallerXml.Bootstrapper.BootstrapperSectionGroup, BootstrapperCore">
            <section name="host" type="Microsoft.Tools.WindowsInstallerXml.Bootstrapper.HostSection, BootstrapperCore" />
        </sectionGroup>
    </configSections>
    <startup useLegacyV2RuntimeActivationPolicy="true">
        <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
    </startup>
    <wix.bootstrapper>
        <host assemblyName="FSCustomBA" />
    </wix.bootstrapper>
</configuration>

I was on the wrong track when I tried multiple variations involving the use of the supportedFramework element. The problem turned out to have nothing to do with that. Instead, the problem was that I followed the example of the WixBA and TestBA applications that are part of WiX, which is to name the BootstrapperCore.config file after the pattern ${ProjectName}.BootstrapperCore.config. Since my project is named FSCustomBA, my BootstrapperCore.config file was named FSCustomBA.BootstrapperCore.config.

This is fine. It can be made to work. However, what I did not realize is that the file must be named BootstrapperCore.config in the context of the .ba directory that is created when the setup package is run. Since I was not aware of this, I included the file in my bundle as follows.

<Payload SourceFile="$(var.FSCustomBA.TargetDir)FSCustomBA.BootstrapperCore.config" />

This will not work. The following will.

<Payload Name="BootstrapperCore.config"  SourceFile="$(var.FSCustomBA.TargetDir)FSCustomBA.BootstrapperCore.config" />

Note the use of the Name attribute in the Payload element. This says to name the file BootstrapperCore.config in the .ba directory.

After I resolved that problem, I next encountered the following error: "0x80131040 : The located assembly's manifest definition does not match the assembly reference." In the log file, this was recorded as an inability to loaded the Managed Bootstrapper Application.

In order to resolve this issue, I simply set the SuppressSignatureVerification attribute to yes for the Payload element associated with my Custom BA. For example, the Payload element I am using is as follows.

<Payload SourceFile="$(var.FSCustomBA.TargetDir)FSCustomBA.dll" SuppressSignatureVerification="yes" />

I think this is only necessary due to the code signing certificate I am using.

My employer uses an official code signing certificate from VeriSign for all official builds. However, the details of this certificate are kept secret even from most of the developers. Developers instead use a self-signed certificate for their day to day work. This works for most things, but apparently not for this.

Now that I have resolved these issues, my Custom Bootstrapper Application is loading and, with the exception of one minor bug, working as expected.

I hope that by documenting my findings, I will save others the headaches I had to go through to solve this problem.

Nelsonnema

Same issue happens if you forget to include the config file in the payloads. Thanks! – Lundy