Choosing Between Shared and Versioned VSPackages
Visual Studio .NET 2002, Visual Studio .NET 2003, and Visual Studio 2005 can coexist on the same computer. VSPackages can support any mix of Visual Studio versions.
You can enable side-by-side installations of VSPackages through either of two strategies, the shared strategy or the versioned strategy. Both accommodate the presence of multiple versions of Visual Studio and their associated versions of the .NET Framework.
In the shared strategy, one VSPackage is registered for use in multiple versions of Visual Studio. In the versioned strategy, multiple VSPackage DLLs are installed, one for each version of Visual Studio that you support.
Shared VSPackages
Using a shared VSPackage is appropriate when you use the same VSPackage in multiple versions of Visual Studio. To implement a shared VSPackage, you must take the following steps:
Make your VSPackage compatible with multiple versions of Visual Studio. Two ways of doing so are available:
Limit your VSPackage to using only the features of the earliest version of Visual Studio that you support.
Program your VSPackage to adapt to the version of Visual Studio in which it is running. Then, if queries for newer services fail, your VSPackage can offer other services that are supported in older versions of Visual Studio.
Register your VSPackage appropriately. For more information, see VSPackage Registration and Managed VSPackage Registration Keys.
Register file extensions appropriately. For more information, see Registering File Extensions for Side-By-Side Deployments.
Create an installer that deploys your VSPackage for the appropriate versions of Visual Studio. For more information, see Installing VSPackages with Windows Installer and Component Management.
Address the issue of registration collisions. For more information, see VSPackage Registration.
Ensure that both shared and versioned files respect reference counting to allow safe installation and removal of multiple versions. For more information, see Component Management.
Versioned VSPackages
Under the versioned VSPackage strategy, you create one VSPackage for each version of Visual Studio that you support. Doing this is appropriate when you expect to take advantage of services provided by later versions of Visual Studio, because each VSPackage can evolve without affecting the others. Nevertheless, the versioned strategy of creating multiple binaries, either from a single code base or from multiple independent code bases, might entail more initial development than the shared strategy. Also, additional setup work might be required because you must create either a separate setup for each version or a single setup that detects the versions of Visual Studio that are installed and that your VSPackage supports.
Binary Compatibility
Generally, binary compatibility enables native-code VSPackages developed with Visual Studio .NET 2002 to run in Visual Studio .NET 2003 and Visual Studio 2005. However, there are three important exceptions:
In Visual Studio .NET 2002, version 1.0 of the .NET Framework and the common language runtime are loaded. In Visual Studio .NET 2003 and Visual Studio 2005, other versions are loaded. So, if your VSPackage relies on a particular version of the common language runtime, then it must determine in which version of Visual Studio it is running.
A VSPackage might have a dependency on a specific feature of another VSPackage or another product, for example, Visual Basic .NET 2002 or Visual C# 2005. Consequently, the VSPackage can run only where the dependency is satisfied.
A VSPackage might be impacted by a security fix in a Visual Studio service pack or a later version of Visual Studio. In those cases, a VSPackage developed with an earlier version of the Visual Studio SDK might not run in those serviced or subsequent versions of Visual Studio. However, you can rebuild your package with the Visual Studio 2005 SDK and have it also run in both Visual Studio .NET 2002 and Visual Studio .NET 2003.
Managed VSPackages must be built using a version of Visual Studio and the Visual Studio SDK that match the target version of Visual Studio. That is, you cannot use Visual Studio 2005 to build a managed VSPackage for Visual Studio .NET 2003.
In addition to planning for binary compatibility for your VSPackage DLLs, you also should consider solution and project file formats. If your VSPackage creates a new project type, you must decide whether it can run in just one version or in multiple versions of Visual Studio. For more information, see How to: Upgrade Project Systems.