Answering follow-up questions about .NET Framework 2.0 setup behavior
I posted some instructions earlier this weekend about how to perform unattended installations of the .NET Framework 2.0 redistributable and SDK. I got a couple of comments with some really good follow-up questions, and I want to address them as a separate post because that will make the answers easier to find than if they were only posted in the comments on the previous post.
What is the most common way to have an application install .NET Framework on to a computer along with an application? Do they typically just include dotnetfx.exe and call that using silent/unattended command-line switches? Or are there merge modules available that an MSI can include to automatically install the .NET Framework?
There are not merge modules available for any versions of the .NET Framework. We worked on one for early versions of the .NET Framework 1.0 but it was cut because of some major serviceability issues. Once a merge module is consumed into another MSI, the bits in the merge module generally have to be serviced using the product code for the MSI that consumes it. That makes it very difficult for a redistributable package like the .NET Framework because there is not a way of knowing exactly which applications will consume your merge module. This issue affected SQL MSDE when the slammer virus hit because a lot of applications consumed the MSDE merge module and there were active, vulnerable versions of MSDE that could not be patchable by our standard patches.
If you plan to install the .NET Framework as part of your setup, you can use one of the following options:
- Carry dotnetfx.exe with your setup package, and have a bootstrapper that will check for the existence of the .NET Framework on the system and spawn dotnetfx.exe for the user if it is not already installed
- Have your setup check for the existence of the .NET Framework on the system and block and point the user to a web site to download and install the .NET Framework themselves if it is not installed.
You will have to weigh the tradeoffs of these options - carrying the .NET Framework results in a larger package size, but also provides a more seamless user experience. Blocking results in a smaller package size because you don't have to carry dotnetfx.exe, but likely will result in user frustration because they will have to find and install the .NET Framework themeselves before being able to install your product.
How will the .NET Framework installer respond if the .NET Framework is already installed on a system? Is it acceptable for a setup package to skip detecting whether the .NET Framework is already installed and always launch dotnetfx.exe, or should we write code that detects if it is installed first, and then invoke dotnetfx.exe only if necessary?
The .NET Framework setup will run in repair mode if it is already installed. Despite this, I recommend that your setup package detect whether or not the .NET Framework is already installed and only run the dotnetfx.exe setup package if it is not already installed for the following reasons:
- This results in a faster installation for users who already have the .NET Framework installed.
- I have seen issues where re-running dotnetfx.exe on a system that already has the .NET Framework plus a service pack installed will result in error messages. You can see this by downloading and running the .NET Framework 1.1 setup package on a system that already has .NET 1.1 and 1.1 SP1 installed.
What is the officially-supported method for detecting whether .NET 2.0 Framework is already installed and the correct version?
The officially supported method of detecting the presence of the .NET Framework 2.0 is to check the following registry key/value:
[HKEY_LOCAL_MACHINE\Software\Microsoft\Net Framework Setup\NDP\v2.0.50727]
Install = 1 (REG_DWORD)
You can take a look at some sample code I wrote to check for the presence of each shipped version of the .NET Framework and the installed service packs (if any).
Regarding the three different versions of the .NET Framework 2.0 - is it correct that the Intel 64 version is for Itanium and that the AMD64 version also covers Intel Xeon with 64-bit extensions?
The Intel 64 version of the .NET Framework 2.0 is intended for Itanium systems. I have not personally used a computer with Intel Xeon hardware with 64-bit extensions. However, based on the information I found in some quick web searches, it appears to be considered an x64 system. That means that you can install the AMD64 version of the .NET Framework 2.0 if you are running an x64 OS, and you can install the the 32-bit version of the .NET Framework 2.0 if you are running a 32-bit OS.