Share via

Pre-installation checks performed by .NET Framework 2.0 setup

  • Article

The setup wrapper for the .NET Framework 2.0 performs several system and prerequisite checks before it allows the user to start installing. This blog post will explain the implementation details of each of the checks that .NET Framework 2.0 setup performs behind the scenes so that you can implement your own checks or enforce higher prerequisite levels if necessary.

If you are planning to deploy the .NET Framework 2.0 to your network or include it as a prerequisite in your setup package, it is very important that you understand what these checks do so that you can verify that the computers on your network will meet the minimum system requirements and deployment will be able to proceed correctly.

In addition, if you are planning to install the .NET Framework 2.0 in silent mode as a part of your installation package, you must be able to check for these conditions yourself or be able to handle cases where these conditions are not met and .NET Framework 2.0 setup fails as a result.

Single instance of setup check

.NET Framework 2.0 setup attempts to acquire a mutex at the beginning of execution. If it is already owned by another process, it exits and tells the user that another instance of setup is already running.

Administrative privileges check

.NET Framework 2.0 setup uses the algorithm documented in this knowledge base article to check whether or not the setup process has the necessary administrative privileges.

OS version check

.NET Framework 2.0 setup first calls the GetVersionEx API. If the dwPlatformId member of the returned OSVERSIONINFO structure equals VER_PLATFORM_WIN32_WINDOWS, then the OS version is Windows 9x and the OS version check is done.

If dwPlatformId equals VER_PLATFORM_WIN32_NT, then setup checks the dwMajorVersion and dwMinorVersion members of the returned OSVERSIONINFO structure.

If dwMajorVersion < 5, then setup blocks installation because Windows NT 4.0 and earlier versions of Windows NT are not supported platforms for installing the .NET Framework 2.0.

If dwMajorVersion is greater than or equal to 5, then the OS is a valid OS to install the .NET Framework 2.0, and the following logic is used to determine exact OS version:

  • Windows 2000: if dwMajorVersion = 5 and dwMinorVersion = 0
  • Windows XP: if dwMajorVersion = 5 and dwMinorVersion = 1
  • Windows Server 2003: if dwMajorVersion = 5 and dwMinorVersion = 2

64-bit OS check

The .NET Framework 2.0 shipped both as 32-bit and 64-bit packages. Setup requires that the version of the .NET Framework 2.0 that matches the current processor architecture be installed, and attempting to install mismatched versions will be blocked.

The 32-bit version of .NET Framework 2.0 setup blocks the user from installing on a 64-bit OS. It does this by checking to see if the current setup process is running in the WOW64 layer. To do this, .NET Framework 2.0 setup attempts to locate the GetSystemWow64Directory API. If this API exists on the system and it returns a valid path, then setup reports that the system is a 64-bit OS and the current instance of setup is a 32-bit process running in the WOW64 layer, and it blocks the user from installing.

The 64-bit version of .NET Framework 2.0 setup will not run on a 32-bit OS. There is not a specific block implemented in setup for this. Instead, setup will display a generic error just like all 64-bit executables do when they are launched on a 32-bit OS. It could be one of the following:

  • If setup is launched from the self-extracting EXE: Error creating process <C:\DOCUME~1\username\LOCALS~1\Temp\IXP000.TMP\Install.exe>. Reason: C:\WINDOWS\system32\advpack.dll
  • If setup is launched by running install.exe directly: install.exe is not a valid Win32 application.
  • If setup is launched by running msiexec.exe /i netfx.msi: This installation package is not supported by this processor type. Contact your product vendor.

Check to see if the .NET Framework 2.0 was installed as part of the OS

.NET Framework 2.0 setup checks to see if it is being run on an OS that already has the .NET Frameowork 2.0 installed as part of the OS. To do this, it checks the following registry value:

  • Key name: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v2.0.50727
  • Value name: OCM
  • Value data type: REG_DWORD
  • Value data: 1

Currently, the only OS that includes the .NET Framework 2.0 is Windows Vista. However, that could change in the future, so the safest way to detect whether the .NET Framework 2.0 is installed as an OS component is to check the above registry value as opposed to trying to detect the OS version.

Microsoft Internet Explorer 5.01 version check

.NET Framework 2.0 setup verifies that the version of Internet Explorer installed on the system is at least version 5.01. To do this, it checks the following registry value:

  • Key name: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer
  • Value name: Version
  • Value data type: REG_SZ
  • Value data: greater than or equal to 5.0.2919.6307

Note that this check requires splitting the Version registry value into 4 different parts by splitting on the period and comparing each part of the version against the minimum values 5, 0, 2919 and 6307. A simple string comparison will not work because, for example, version 2.0.0.0 would be greather than 10.0.0.0 when using a string comparison.

Windows Installer version check

.NET Framework 2.0 setup validates the Windows Installer version installed on the system. To do this, it first determines the location of msi.dll by checking the following registry value:

  • Key name: HKEY_LOCAL_MACHINE\ SOFTWARE\ Microsoft\ Windows\ CurrentVersion\ Installer
  • Value name: InstallerLocation
  • Value data type: REG_SZ

The InstallerLocation value will contain a folder path. .NET Framework 2.0 setup then appends msi.dll to the value of the InstallerLocation value, and loads and attempts to call the DllGetVersion API in msi.dll. If that API returns success, setup checks for the following return values:

  • If the OS is Windows 9x: dwMajorVersion is greater than or equal to 2 and dwMinorVersion is greater than or equal to 0
  • If the OS is Windows 2000 or later: dwMajorVersion is greater than or equal to 3 and dwMinorVersion is greater than or equal to 0

Note that while the initial .NET Framework 2.0 setup only checks for Windows Installer 3.0 or later on Windows 2000 and later, hotfixes and service packs for the .NET Framework 2.0 will require Windows Installer 3.1 or later in order to install correctly. As a best practice, your setup should enforce that Windows Installer 3.1 is present as well.

Previous beta product check

.NET Framework 2.0 setup uses the algorithm in this blog post to check for previous beta products that are installed on the system.

.NET Framework 2.0 already installed check

In order to determine whether or not to enter maintenance (repair/uninstall) mode or not, .NET Framework 2.0 setup checks to see if the .NET Framework 2.0 MSI is already installed on the system. It retrieves the product code for netfx.msi, then calls the MsiQueryProductState API and passes in this product code. If MsiQueryProductState returns INSTALLSTATE_DEFAULT, then setup enters maintenance mode. Otherwise, setup enters initial install mode.

Comments

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

  • Anonymous
    July 09, 2006
    If you wondered what type of checks the the setup wrapper for the .NET 2.0 Framework performed?&amp;nbsp;...

  • Anonymous
    July 09, 2006
    アプリケーションのインストール時の確認事項とその方法

  • Anonymous
    July 12, 2006
    A few days ago, I wrote a blog entry describing the prerequisites for the .NET Framework 2.0 and how...

  • Anonymous
    August 26, 2006
    PingBack from http://www.pcwelt.de/forum/windows-xp-server-2003/216955-advpack-dll-kaputt.html#post1142914

  • Anonymous
    September 15, 2006
    Hello Aaron!

    Thank's for providing this and all the other information in this blog ... it's a gread work!

    One question about
    > NET Framework 2.0 already installed check
    Is it possible that this check prevents an administrative installation (you described in http://blogs.msdn.com/astebner/archive/2005/11/17/494312.aspx) how to do that) on a machine where the .NET Framework 2.0 is already installed?

    I tried to deploy the .NET Framework using msiexec like you described it.  After a few trials the creation of the administrative install using install.exe /a throw out an error ...

    I will redo / re-check the steps i did yesterday late in the evening and provide additional information here.

    Greetings

    Reinhard

  • Anonymous
    September 15, 2006
    Hi MrWinstonWolf - Please let me know more details about the error that you saw so I can try to help.  You should be able to look in your %temp% directory for logs starting with the name dd_netfx20* to find a verbose log that will help narrow down the failure.  If you're not able to figure anything out, please contact me at Aaron.Stebner (at) microsoft (dot) com and send me the log files and I can try to take a look as well.

  • Anonymous
    September 15, 2006
    Hello Aaron!


    Many thanks for offering your help to me.  Please give me a little bit of time to make sure that I can reconstruct the problem in an absolutely clear configuration.

    The actual situation is that I am able to reconstruct the described behaviour - but I want to be absolutely sure.  I have an assumption (not really a big one, but it is an assumption) that I made something wrong.

    Of course I will post the results of my experiments here.

    The unpleasant part of the actual situation is that the first try to create an administrative installation point is successful.  The problem occurs when I try to recreate that administrative installation point (assuming and simulating a damage of this folder).  The logfile tells me to uninstall .NET Framework - but uninstallation via Control Panel / Software throws out an error message telling me that the package 'langpack.msi' could not be opend.

    That means that I have to reinstall my (test) system to get back an defined state for further experiments. And this takes some time ... I swear an oath that I will invest a little bit of money in a new and more powerful computer ASAP ;)


    Greetings

    Reinhard

  • Anonymous
    September 17, 2006
    Hi MrWinstonWolf - I have not heard of any problems like this before.  Also, I don't understand why there is an entry in Add/Remove Programs if all you are doing is creating an administrative install point.  Can you please list the exact command lines that you run in order to reproduce this 'langpack.msi' error that you've been seeing?

  • Anonymous
    June 19, 2007
    アプリケーションのインストール時の確認事項とその方法

  • Anonymous
    July 18, 2007
    The comment has been removed

  • Anonymous
    January 24, 2008
    Would be great to see a similar blog about .NET 1.1  Having great difficulty in getting it installed on any 64-bit servers.  Supposedly works under WoW64 but installer says: "This setup is not supported on 64-bit versions of Windows XP"  (even though this is Server 2003) The silence on the web is deafening WRT this issue.  Though several people have reported it in various forums no one has an answer.