Detecting Visual Studio 2005 Service Pack 1
Now that Visual Studio 2005 Service Pack 1 is released, it can be detected programmatically in various ways. Registry detection is recommended for ease and is less impacted by future changes to the product installation. Because there are many different Visual Studio 2005 editions and service pack 1 patch packages, you may need to perform several patch existence tests if you support a more general scope. For example, if you have a plug-in that supports Visual Studio 2005 Standard, Professional, or Team editions – regardless of languages – you may need to perform 9 tests for all the supported languages service pack 1 targets.
All the registry keys I previously documented are still supported as required, so you can determine if a service pack is installed for a particular product given its ProductName (which is always in English, which is not necessarily the name you'll see in Add/Remove Programs) and the KB number of the service pack patch. The other registry keys I document below may not be supported in future versions.
If you don't need to be specific about a particular Visual Studio 2005 SKU, you can detect SP1 for a particular written language (for VSTS and TFS) or for a particular project language (for Express SKUs) using an older registry key under,
HKEY_LOCAL_MACHINE\Software\Microsoft\Active Setup\Installed Components\{PatchCode}
You can find the {PatchCode} in the .msp file. In Windows 2003 and earlier platforms, you'll see this as the Revision number property in the properties Summary tab in Windows Explorer. In all cases, you can query the Summary Information stream or open the .msp file in Orca, then click the View -> Summary Information menu item.
For the English Visual Studio 2005 Service Pack 1 for Standard, Professional, and Team editions (VS80sp1-KB926601-X86-ENU) an example of the registry key above follows.
HKEY_LOCAL_MACHINE\Software\Microsoft\Active Setup\Installed Components\{D93F9C7C-AB57-44C8-BAD6-1494674BCAF7}
You can also determine the service pack level of a more general, larger scope by reading a REG_DWORD registry value named SP from under,
HKEY_LOCAL_MACHINE\Software\Microsoft\DevDiv\[ProductFamily]\Servicing\8.0
…and for a specific language SKU using a sub-key,
HKEY_LOCAL_MACHINE\Software\Microsoft\DevDiv\[ProductFamily]\Servicing\8.0\[ProductEdition]\[ProductLanguage]
Product families are pretty broad in scope, and include for "Whidbey":
- URT (.NET Framework, once known as the Universal Runtime)
- VB (Microsoft Visual Basic 2005 Express)
- VC (Microsoft Visual C++ 2005 Express)
- VCS (Microsoft Visual C# 2005 Express)
- VJS (Microsoft Visual J# 2005 Express)
- VNS (Microsoft Visual Web Developer 2005 Express)
- VS (Visual Studio 2005 Standard, Professional, Team Suite, etc.)
- VSTF (Visual Studio 2005 Team Foundation Services)
An example using the English Visual Studio 2005 Team Suite Service Pack 1 of the registry keys above follows. Under each key you would find a registry value named SP set to 1.
HKEY_LOCAL_MACHINE\Software\Microsoft\DevDiv\VS\Servicing\8.0
HKEY_LOCAL_MACHINE\Software\Microsoft\DevDiv\VS\Servicing\8.0\VSTS\1033
Visual Studio 2005 Express SKUs will always use the ProductEdition of EXP, so you can combine the ProductFamily values documented above with EXP to form registry keys like the following, for Visual C# 2005 Express.
HKEY_LOCAL_MACHINE\Software\Microsoft\DevDiv\VCS\Servicing\8.0
HKEY_LOCAL_MACHINE\Software\Microsoft\DevDiv\VCS\Servicing\8.0\EXP\1033
Of course there are other ways, ranging from using a DrLocator search in a Windows Installer package for a specific version range of a file, to actually calling Windows Installer APIs, such as MsiGetPatchInfo or MsiGetPatchInfoEx with the same {PatchCode} as described above. Since for Visual Studio 2005 our service packs are minor upgrade packages, you can also use APIs that take machine state into account – like MsiOpenPackage or MsiOpenPackageEx – and check the ProductVersion property since it will have changed. Note that the .NET Framework 2.0 on Vista is not Windows Installer-based, so Windows Installer query APIs cannot be used for the Framework.
