How to detect old beta versions when deploying the .NET Framework 2.0
I was talking to a couple of Microsoft product teams a couple of weeks ago. They are trying to figure out the best way to integrate the .NET Framework 2.0 setup package into their own setup since their products require the .NET Framework 2.0 on the system in order to function correctly.
One of the teams has already shipped a beta version in which they pre-installed the .NET Framework by running dotnetfx.exe in silent mode if their setup detected that the .NET Framework 2.0 was not already installed n the system. They were seeing a fairly high failure rate in .NET Framework 2.0 setup and had tracked down the root cause to beta versions of the .NET Framework 2.0 or Visual Studio 2005 left on their customers' computers. They had been reading through some of my blog posts regarding .NET Framework 2.0 deployment issues and asked for some advice regarding this beta version detection scenario.
As I looked through the various topics I have written about regarding deployment of the .NET Framework, I realized I had not yet covered the topic of detecting beta versions at all. Therefore, I decided to summarize the advice I sent to these teams and describe how I would recommend that applications that need to pre-install the .NET Framework 2.0 as part of their setup package handle beta version issues.
The most reliable way to handle beta version detection in order to minimize .NET Framework 2.0 setup failures is to implement a strategy in your setup package that behaves the same way as the .NET Framework 2.0 beta detection logic.
There is a list of product codes in the [BlockProductCode] section of the file install.ini that is included as part of the self-extracting dotnetfx.exe package. These product codes represent all MSI product codes for beta versions of the .NET Framework 2.0 and Visual Studio 2005 that are known to cause compatibility problems with the final release of the .NET Framework 2.0. You can extract install.ini by downloading the .NET Framework 2.0 setup package and then running dotnetfx.exe /t:c:\temp /c and navigating to c:\temp.
The following algorithm describes how .NET Framework 2.0 setup detects and blocks when it finds incompatible beta products:
For each (beta product code)
{
Call MsiQueryProductState to check if the install state for the product code equals INSTALLSTATE_DEFAULT
if (install state == INSTALLSTATE_DEFAULT)
{Call MsiGetProductInfo to retrieve the INSTALLPROPERTY_INSTALLEDPRODUCTNAME property for the product code
Add the value of the INSTALLPROPERTY_INSTALLEDPRODUCTNAME property to the list of beta products that need to be uninstalled}
}
If (list of beta products is not empty)
{
If (setup is running in full UI mode)
{Display UI with a list of product names that need to be uninstalled via Add/Remove Programs
}
Exit setup with return code 4113
}
By using the above algorithm with the same set of product codes, you will be able to catch most cases where the .NET Framework 2.0 setup would otherwise fail due to incompatible beta products. There are a few cases that could still cause .NET Framework 2.0 setup failures, but those are mostly due to broken beta uninstalls, and the root causes are generally non-deterministic, so there is not a reliable way to detect them in your setup package.