Detecting Patches in .NET 2.0 and Visual Studio 2005

Heath Stewart

Aaron Stebner posted some sample code to detect whether the .NET Framework 1.0, 1.1, or 2.0 were installed and at what service pack level they are. Basically, the .NET Framework installation writes a common, version-specific registry key in the following location along with an SP level registry value. The sample below for an English (United States) installation of .NET 2.0 is shown using the registry file format.

[HKEY_LOCAL_MACHINESOFTWAREMicrosoftNET Framework SetupNDPv2.0.50727]
“Install”=dword:00000001
“MSI”=dword:00000001
“SP”=dword:00000000

[HKEY_LOCAL_MACHINESOFTWAREMicrosoftNET Framework SetupNDPv2.0.507271033]
“Install”=dword:00000001
“MSI”=dword:00000001
“SP”=dword:00000000

To detect if service pack 1 is installed, check that the “SP” value is 1.

If you need to detect a specific hotfix patch you should note the KB article number and follow the specific steps to determine if the hotfix is installed. Also note which SP level (including RTM) the hotfix targets.

1. Check the service pack level as described above.
   • If the SP value in the registry is greater then the target SP level of the hotfix, the changes made by the hotfix are installed. Please note that there are rare exceptions to this rule. You are finished detecting for a specific patch.
   • If the SP value in the registry is equal to the target SP level of the hotfix, proceed with the following steps.
2. Check for the KB article number under HKEY_LOCAL_MACHINESoftwareMicrosoftUpdates[ProductName], where [ProductName] is the value of the ProductName property in the Property table of the application set .msi file. Below is another sample registry format file for a patch targeting the release of .NET Framework 2.0. You would want to check that the value “Installed” in bold exists. The example is for a fictitious KB123446.

[HKEY_LOCAL_MACHINESOFTWAREMicrosoftUpdatesMicrosoft .NET Framework 2.0KB123456]
“Installed”=dword:00000001
“UninstallCommand”=”C:\WINDOWS\system32\msiexec.exe /promptrestart /uninstall {633ECF8F-DAD3-4E23-AAD6-52D6386C9099} /package {7131646D-CD3C-40F4-97B9-CD9E4E6262EF}”
“ARPLink”=”HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\KB123456.T1_1ToU60_1”
“InstallerVersion”=”3.01”
“PublishingGroup”=”Developer Division Customer Product-lifecycle Experience”
“Publisher”=”Microsoft Corporation”
“PackageVersion”=”1”
“PackageName”=”Hotfix for Microsoft .NET Framework 2.0 (KB123456)”
“ReleaseType”=”Hotfix”
“Type”=”Update”
“InstalledDate”=”4/7/2006”
“Description”=”This Hotfix is for Microsoft .NET Framework 2.0. \n
If you later install a more recent service pack, this Hotfix will be uninstalled automatically. \n
For more information, visit http://support.microsoft.com/kb/123456″
“AppliedToSP”=”R1”
“InstalledBy”=”Heath Stewart”

When a new hotfix patch supersedes. or replaces, an older installed hotfix patch, the registry detection keys described above will not be deleted. The superseding patch does not write the detection keys of superseded patches, however. This is a change from .NET Framework 1.0 and 1.1 but we are working to make patch detection common throughout products from Microsoft and are pushing toward patch detection as provided by Windows Installer for Windows Installer-installed patches.

If you rely on a fix within a certain file, you can also check the file version and compare the component parts of the dotted-quad version format. For Windows Installer packages, you can use the DrLocator table, along with the Signature table and the AppSearch table to set a property if a file version is within a given range of version numbers. If you rely on the LaunchCondition table to check for the existence of the property to be set if the file exist within the given version range, make sure to schedule the standard AppSearch action before the standard LaunchConditions action.

Heath Stewart Senior Software Engineer, Azure SDK

Follow