PLK's, Supporting Multiple Versions of VS with a single VS Package
I got a question today after some confusion regarding Package Load Keys for Visual Studio and how to get a package to work in multiple versions of VS.
Here's my response:
PLK (Package Load Key)
The PLK's are issued for either VS2002 or VS2003/2005.
In order to support 2003 and 2005 with the same binary, the package must place the exact same data in the registry for both installations. This means that there can be no version number changes (as in the registry, the file version or assembly version number doesn’t matter), no company name changes, no package name changes, etc.
So if a package was originally developed to support VS2002 an appropriate package load key is needed and the package is registered under the VS2002 hive at "HKLM/Software/Microsoft/VisualStudio/7.0". In order to get the same package without changes to work on VS2003 then the package vendor needs to get a new PLK. The package vendor then has an opportunity to change some of the information in the registry (version number, company name, package name, etc). For VS2003 the package is registered under the VS2003 registry hive "HKLM/Software/Microsoft.VisualStudio/7.1". If the same package is intended to work without changes on VS2005, then it simply needs to be registered under the VS2005 registry hive "HKLM/Software/Microsoft/VisualStudio/8.0". It’s important to note that no registry changes (other than the registry hive) between 2003 and 2005 can take place in order to get the PLK to work on both 2003 and 2005.
If changes in the registry information are desired (whether for a new version or other changes the company may want to make), the package vendor is always free to request a new PLK providing the new registry information. This is true regardless of VS version and is true intra-version as well (like I want my package to work on 2002 and then I need to make a change and still want it to work on 2002).
The important bit to know here is the as far as PLK's are concerned, VS2003 and VS2005 are equivalent. They both use the same cryptographic information to validate the PLK's. VS2002, however, uses a different cryptographic key which is why VS2002 packages have to request a different PLK.
In a future version of VS, we may change the cryptographic validation information and this would require all 3rd party packages to get new PLK’s in order to work on that version of VS. We have no specific plans that I can comment on at this time.
Load-time Binary Compatibility
That said, there's also the issue of binary compatibility. For instance, if I build a managed package with VS2005 it depends on the .Net Framework 2.0 and may have other dependencies as well. That binary will not load on a VS2003 installation that only has the 1.0 and 1.1 .Net Frameworks. Even if the PLK issues above were satisfied in this case, the binary compatibility of the platform doesn’t support this type of configuration. This is further exacerbated by the fact that only one version of the CLR can be run inside a given process and the VS process (devenv.exe) will only load the version of the CLR for which is was built (VS2002 & 1.0 CLR, VS2003 & 1.1 CLR, VS2005 & 2.0 CLR). One cannot simply install the 2.0 version of the CLR in order to get the previously mentioned configuration to work.
For managed packages, it is possible to build a package in VS2003 with the VSIP 2003 + VSIP 2003 Extras SDK's and then have that package to work in VS2005. VS2005, in this sense, is backward compatible with VS2003. The same holds true outside of VS as long as there have been no breaking changes in the underlying types depended upon by the assembly (in other words something written for 1.0 of the CLR should still run on 2.0 of the CLR (with few exceptions)).
For native code, since there is more freedom and looser coupling of dependencies, it is possible to write a package in VS2005 that can run on VS2003 or VS2002, but special care must be taken to satisfy any dependencies the package requires (like the version of the C runtime or ATL or MFC, etc).
Runtime Binary Compatibility
There is also the notion of 'adaptive packages' within this discussion. These are packages that, once all PLK and loading dependencies have been satisfied, can react at runtime to features of VS that exist or not. For instance if I write a package that consumes a certain service and this service is not available on one of the VS platforms the package runs on, then I need to write the package in such a way that it can gracefully degrade its behavior without compromising the entire functionality of the package. This is easy to accomplish in native COM code, but more difficult in managed code (because of tight coupling of types like interfaces, structs, etc).
I hope this explanation helps.
Allen