How to intelligently install .NET 4.x using WiX Burn

Question

When installing an application that can use either .NET 4.0 or 4.5, what is the best practice when installing the prerequisites .NET framework? And how do you implement it using Burn in WiX?

These are the options and trade-offs that I am aware of:

Option 1: Install .NET 4.0 (just what you need)

• Advantages: None known (except for Windows XP, where this is the only choice)

Option 2: Install .NET 4.5 if .NET 4.5 is not present

• Advantages: User won't have to install .NET 4.5 later for future apps. App won't experience a .NET version change when user later does upgrade to .NET 4.5. App immediately gets performance improvements of .NET 4.5.

Option 3: Install .NET 4.5 only if neither .NET 4.x is present

• Advantages: Much faster deployment than option 2 if .NET 4.0 is already installed. If it's not, then the advantages of option 2 apply.

As far as I can tell, the best practice would be option 2 if the performance improvements are important and option 3 if average deployment speed is important. Does this sound right? Am I missing any advantage to option 1? Most importantly, if option 3 does make sense, how do you implement it using Burn when installing .NET from the web?

Answer 1

Below is how I detect .NET in my bundle. Note the use of DetectConditions and InstallConditions. The DetectCondition will check whether or not the specific package is installed, whereas the InstallCondition can be used to override the DetectCondition to specify when the package should be installed. For example, on XP you can't install .NET 4.5 so my InstallCondition prevents installation in such a case.

<util:RegistrySearch Root="HKLM" Key="SOFTWARE\Microsoft\Net Framework Setup\NDP\v4\Full" Value="Version" Variable="Netfx4FullVersion" />
<util:RegistrySearch Root="HKLM" Key="SOFTWARE\Microsoft\Net Framework Setup\NDP\v4\Full" Value="Version" Variable="Netfx4x64FullVersion" Win64="yes" />

<!-- .NET 4.5 only installed if Vista or higher AND it's not already installed-->
<PackageGroup Id="Netfx45">
  <ExePackage Id="Netfx45" Cache="no" Compressed="yes" PerMachine="yes" Permanent="yes" Vital="yes" InstallCommand="/q"
              SourceFile="C:\Program Files\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages\DotNetFX45Full\dotnetfx45_full_x86_x64.exe"
              DetectCondition="(Netfx4FullVersion=&quot;4.5.50709&quot;) AND (NOT VersionNT64 OR (Netfx4x64FullVersion=&quot;4.5.50709&quot;))"
              InstallCondition="(VersionNT >= v6.0 OR VersionNT64 >= v6.0) AND (NOT (Netfx4FullVersion=&quot;4.5.50709&quot; OR Netfx4x64FullVersion=&quot;4.5.50709&quot;))"/>
</PackageGroup>
<!-- .NET 4.0 only installed if XP AND it's not already installed -->
<PackageGroup Id="Netfx4Full">
  <ExePackage Id="Netfx4Full" Cache="no" Compressed="yes" PerMachine="yes" Permanent="yes" Vital="yes" InstallCommand="/q"
              SourceFile="C:\Program Files\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages\DotNetFX40\dotNetFx40_Full_x86_x64.exe"
              DetectCondition="Netfx4FullVersion AND (NOT VersionNT64 OR Netfx4x64FullVersion)"
              InstallCondition="(VersionNT &lt; v6.0 OR VersionNT64 &lt; v6.0) AND (NOT (Netfx4FullVersion OR Netfx4x64FullVersion))"/>
</PackageGroup>

Then if you want to install one of the packages, just reference it in your chain:

<Chain>
  <PackageGroupRef Id='Netfx45'/>
</Chain>

With regards to your specific question, I would install whatever framework version the application was tested against. If tested against both .NET 4.0 and .NET 4.5 I suppose it is a judgement call, however I would try to simplify the setup experience as much as possible. So if .NET 4.0 were already installed and the application does not require .NET 4.5, I would not install it.

Also, there is a disadvantage to Option 2 if you are using a custom Managed Bootstrapper Application. Let's say you have .NET 4.0 installed and your managed bootstrapper requires .NET 4.0 (or greater). When you run the installer it will install .NET 4.5 which replaces .NET 4.0, forcing your installer to reboot halfway through because it was using .NET framework at the same time it was being updated. Again, this is only an issue if you are using your own custom managed bootstrapper.