Detecting Visual Studio 2005 Service Pack 1

Detecting Visual Studio 2005 Service Pack 1

  • Comments 10

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.

Leave a Comment
  • Please add 7 and 5 and type the answer here:
  • Post
  • I've just finished my guide about upgrading TFS V1 to WSS 3.0 and Microsoft immediately releases Service

  • In you were out the second half of December, you might have missed some of the VS 2005 Service Pack 1

  • In you were out the second half of December, you might have missed some of the VS 2005 Service Pack 1

  • Heath Stewart has written several very useful blog posts about Visual Studio 2005 SP1 that I wanted to

  • 【原文地址】 A few VS 2005 SP1 Links and Information Nuggets 【原文发表日期】 Monday, January 01, 2007 8:24 PM 如果你在12月份的下半个月出去了,你也许错过了我早先写的几篇关于VS

  • 【原文地址】 A few VS 2005 SP1 Links and Information Nuggets 【原文发表日期】 Monday, January 01, 2007 8:24 PM 如果你在12月份的下半个月出去了,你也许错过了我早先写的几篇关于VS

  • I am interested in installing SP1 to address a couple of errors I'm getting when I try to Rebuild the Setup Package.  Our company develops in VS2005 on our desktop PCs, then publishes the final version on a Citrix farm for use by the operator(s).  We currently have VS2005 also installed on the Citrix servers.  If I install SP1 on my development PC, will I also need to install SP1 on the Citrix servers?

    I wasn't sure where to post this comment, but I thought that if the answer is Yes, I can see where this detection would be necessary for me.

  • Shawn, you'll need to install SP1 anywhere you need its fixes. So, if you're rebuilding the setup package on your Citrix servers you will need to install SP1 for the same fix as you require on your development machines.

  • No doubt you've heard the Microsoft .NET Framework 3.5 was released . Aaron Stebner has posted a list

  • The Visual Studio 2008 RTM and SP1 detection keys are largely the same as the Visual Studio 2005 SP1

Page 1 of 1 (10 items)