Let's Code - WiX: On to .NET Framework v4.5

Like a dependency on .NET Framework v3.5. But v3.14 is a “stepping-stone” release to WiX v4.0 so it’s time to move to a more recent .NET Framework. Sound good? I thought so. Let’s code!

Checkout

So here is the plan:

1. The parts of the WiX Toolset that run on end-users machines (think DTF and MBA) will continue to target .NET Framework 2.0 but manifested to run on .NET Framework v4.x.

2. The parts of the WiX Toolset that run in the build lab will target .NET Framework v4.5 because that’s more than good enough for our needs.

3. If a machine does not have .NET Framework v4.5 or better installed the WiX Toolset build tools bundle will install .NET Framework v4.6.2.

You may be scratching your head on that last one. The reasoning is that if you have a computer without .NET Framework v4.5+ then we’ll install what you’d get via Windows Update. By the time we’re done with WiX v4.0 we may move up to .NET Framework v4.7.

So that’s what we’re doing. I expect this will be mostly an exercise in deleting code.

git fetch upstream
git merge --ff --ff-only upstream/develop
git checkout -b netfx45

Commit

First step is to change the default. We centralize as much of our build configuration in the tools\ folder. So updating the default TargetFrameworkVersion for all of the WiX Toolset is simply a matter of changing the v3.5 in tools\WixBuild.csproj.props to v4.5. I do the same in the tools\WixBuild.vcxproj.props so our Managed C++ code also targets .NET Framework v4.5.

Next I scan all the projects looking for any that explicitly override the TargetFrameworkVersion. I find a couple that called out v3.5 (WixTasks), v4.0 (lux) and v4.5 (VSExtension) that can now use the default. See. Code deletion already.

I also take this opportunity to remove the useLegacyV2RuntimeActivationPolicy="true" and <supportedRuntime version="v2.0.50727" /> from all the command-line tools’ app.configs since we no longer support .NET Framework v2.0 for the build tools. More deletion.

After a quick build, I discover that the SecurityPermission attribute is deprecated. Do you remember CAS? No, I don’t expect you do. Neither does the .NET Framework. More code deleted.

I pause and consider wix.targets, wix200x.targets and wix2010.targets. The latter two are the MSBuild targets files that do the real heavy lifting. There are two because it got too hard to support both MSBuild v3.5 and v4.0 with one set of targets files. Did I mention our commitment to backwards compatibility?

The first file, wix.targets exists to import the correct targets file based on the MSBuild version.

Anyway, MSBuild v3.5 support is gone so wix200x.targets can go too. And that means that wix.targets only has one file to choose. So wix2010.targets can become wix.targets. Cool. Huge amounts of code deleted.

That just leaves us setup.

The Bundle.wxs change is trivial. Remove the search for .NET Framework v3.5 and include the .NET Framework v4.6.2 as our prerequisite.

Then we go into the WixBA.BootstrapperCore.config and indicate that we want to run in .NET Framework v4.5 like so:

<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />

Finally, into the InstallationViewModel.cs to remove the code that blocks if .NET Framework v3.5 is not found. We can do that because the mbapreq will automatically kick in and install the .NET Framework v4.6.2 if our BA cannot loaded on .NET Framework v4.5 or later.

And… we’re not done.

I have to go do all of the above for WiX v4.0. I won’t bore you with those details. But this duplicative effort between v3.x and v4.x is the primary reason only work that helps migration from v3.x to v4.x is allowed in v3.14.

Anyway, we are done with the the work for v3.14.

git add -A .
git commit

    > Standardize WiX Toolset on .NET Framework v4.5

Pull request (v3.14) Pull request (v4.0)

Until next time! Keep coding. You know I am.