Detecting Patches in .NET 2.0 and Visual Studio 2005

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
.