Skip to content

Latest commit

 

History

History
78 lines (59 loc) · 6.58 KB

choosing-between-shared-and-versioned-vspackages.md

File metadata and controls

78 lines (59 loc) · 6.58 KB
title ms.custom ms.date ms.reviewer ms.suite ms.technology ms.tgt_pltfrm ms.topic helpviewer_keywords ms.assetid caps.latest.revision ms.author manager translation.priority.mt
Choosing Between Shared and Versioned VSPackages | Microsoft Docs
11/04/2016
vs-ide-sdk
article
SxS
side-by-side installation
installation [Visual Studio SDK], side-by-side
e3128ac3-2e92-48e9-87ab-3b6c9d80e8c9
22
gregvanl
ghogen
cs-cz
de-de
es-es
fr-fr
it-it
ja-jp
ko-kr
pl-pl
pt-br
ru-ru
tr-tr
zh-cn
zh-tw

Choosing Between Shared and Versioned VSPackages

Different versions of Visual Studio can coexist on the same computer. VSPackages can support any mix of [!INCLUDEvsprvs] 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 [!INCLUDEvsprvs] and associated versions of the [!INCLUDEdnprdnshort].

In the shared strategy, one VSPackage is registered for use in multiple versions of [!INCLUDEvsprvs]. In the versioned strategy, multiple VSPackage DLLs are installed, one for each version of [!INCLUDEvsprvs] that you support.

Shared VSPackages

Using a shared VSPackage is appropriate when you use the same VSPackage in multiple versions of [!INCLUDEvsprvs]. To implement a shared VSPackage, you must take the following steps:

Versioned VSPackages

Under the versioned VSPackage strategy, you create one VSPackage for each version of [!INCLUDEvsprvs] that you support. Doing this is appropriate when you expect to take advantage of services provided by later versions of [!INCLUDEvsprvs], 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 [!INCLUDEvsprvs] that are installed and that your VSPackage supports.

Binary Compatibility

Generally, binary compatibility enables native-code VSPackages developed with earlier versions of Visual Studio to run in later versions of Visual Studio. However, there are three important exceptions:

  • If your VSPackage relies on a particular version of the common language runtime, then it must determine in which version of [!INCLUDEvsprvs] it is running.

  • A VSPackage might have a dependency on a specific feature of another VSPackage or another product. Consequently, the VSPackage can run only where the dependency is satisfied.

  • A VSPackage might be affected by a security fix in a [!INCLUDEvsprvs] service pack or a later version of [!INCLUDEvsprvs]. In those cases, a VSPackage developed with an earlier version of the [!INCLUDEvsipsdk] might not run in versions of [!INCLUDEvsprvs] after the security fix was applied. However, you can rebuild your package with the later version and have it also run in earlier versions.

Managed VSPackages must be built using a version of [!INCLUDEvsprvs] and the [!INCLUDEvsipsdk] that match the target version of [!INCLUDEvsprvs].

In addition to planning for binary compatibility for your VSPackage binaries, 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 [!INCLUDEvsprvs]. For more information, see Upgrading Custom Projects.

See Also

Installing VSPackages With Windows Installer
Component Management