Share via

How to detect old beta versions when deploying the .NET Framework 2.0

  • Article

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.

Comments

  • Anonymous
    June 13, 2006
    PingBack from http://blogs.msdn.com/astebner/articles/574618.aspx

  • Anonymous
    July 02, 2006
    I have gotten several questions in the past from customers who need to install the .NET Framework 2.0...

  • Anonymous
    July 09, 2006
    The setup wrapper for the .NET Framework 2.0 performs several system and prerequisite checks before it...

  • Anonymous
    July 10, 2006
    The comment has been removed

  • Anonymous
    August 31, 2006
    How to detect old versions when deploying the .NET Framework 3.0 (formerly WinFX) Via Aaron Stebner's

  • Anonymous
    November 28, 2006
    A while back, I posted a list of possible return codes for the .NET Framework 2.0 . I recently found

  • Anonymous
    July 18, 2007
    The comment has been removed

  • Anonymous
    August 17, 2009
    Hello, I been having issues running my copy of VS2005 Team Suite Edition since I applied VS2005 SP1.   After encountering several issues with the re-installation of VS2005, I uninstalled VS2005 SP1, VS2005 and .Net framework 2.0 as well, know I am in a spiral chasing my tail... When attempt to install .NET 2.0 from the VS2005 CD I get the following error:

Microsoft .NET Framework 2.0 Setup

Setup cannot continue because this version of the .NET Framework is incompatible with a previously installed one.  For more information, see http://support.microsoft.com/support/kb/articles/q312/5/00.asp

OK  

Looking at the Add/Remove wizard I don't see .NET framework 2.0 listed, I also attempted some of the suggested fixes posted on your weblogs, but to no avail. Not to confuse matters, my final goal is to re-install & use my copy of VS2005 Team Suite, but my attempts are met with the following message:

Microsoft Visual Studio 2005 Setup

Error 1935.An error occurred during the installation of assembly 'CrystalDecisions.VSDesigner,Version="10.2.3600.0",FileVersion="10.2.51014.0",PublicKeyToken="692fbea5521e1304",Culture="neutral",ProcessorArchitecture="MSIL"'. Please refer to Help and Support for more information. HRESULT: 0x8002802F.

OK  

and

Microsoft Document Explorer 2005 Setup

Error 1935.An error occurred during the installation of assembly 'Microsoft.VisualStudio.VSContentInstaller,Version="8.0.0.0",PublicKeyToken="b03f5f7f11d50a3a",Culture="neutral",FileVersion="8.0.50727.42",ProcessorArchitecture="MSIL"'. Please refer to Help and Support for more information. HRESULT: 0x8002802F.

OK  

I think I am getting these failure because NET 2.0 is not installed properly, even after the .NET 2.0 uninstallation I can see the following folder with its content: WINDOWSMicrosoft.NETFrameworkv2.0.50727 Your guidance would be greatly appreciated. Rafter