Choosing the Installation Directory for a VSPackage
Note
This article applies to Visual Studio 2015. If you're looking for the latest Visual Studio documentation, see Visual Studio documentation. We recommend upgrading to the latest version of Visual Studio. Download it here
A VSPackage and its supporting files must be on a user's file system. The location depends on whether the VSPackage is managed or unmanaged, your side-by-side versioning scheme, and user choice.
Unmanaged VSPackages
An unmanaged VSPackage is a COM server that can be installed in any location. Its registration information must accurately reflects its location. Your installer user interface (UI) should provide a default location as a subdirectory of the ProgramFilesFolder Windows Installer property. For example:
[ProgramFilesFolder]MyCompany\MyVSPackageProduct\V1.0\
The user should be allowed to change the default directory to accommodate users who keep a small boot partition and prefer to install applications and tools on another volume.
If your side-by-side scheme uses a versioned VSPackage, you can use subdirectories to store different versions. For example:
[ProgramFilesFolder]MyCompany\MyVSPackageProduct\V1.0\2002\
[ProgramFilesFolder]MyCompany\MyVSPackageProduct\V1.0\2003\
[ProgramFilesFolder]MyCompany\MyVSPackageProduct\V1.0\2005\
Managed VSPackages
Managed VSPackages can also be installed in any location. However, you should consider always installing them to the global assembly cache (GAC) to reduce assembly load times. Because managed VSPackages are always strong-named assemblies, installing them in the GAC means that their strong-name signature verification takes only at installation time. Strong-named assemblies installed elsewhere in the file system must have their signatures verified every time they are loaded. When you install managed VSPackages in the GAC, use the regpkg tool's /assembly switch to write registry entries pointing to the assembly's strong name.
If you install managed VSPackages in a location other than the GAC, follow the earlier advice given for unmanaged VSPackages for choosing directory hierarchies. Use the regpkg tool's /codebase switch to write registry entries pointing to the path of the VSPackage assembly.
For more information, see Registering and Unregistering VSPackages.
Satellite DLLs
By convention, VSPackage satellite DLLs — which contain resources for a particular locale — are located in subdirectories of the VSPackage directory. The subdirectories correspond to locale ID (LCID) values.
Managing VSPackages indicates that registry entries control where Visual Studio actually looks for a VSPackage's satellite DLL. However, Visual Studio tries to load a satellite DLL in a subdirectory named for an LCID value, in the following order:
Default LCID (VS LCID for example \1033 for English)
Default LCID with the default sublanguage.
System default LCID.
System default LCID with the default sublanguage.
U.S. English (.\1033 or .\0x409).
If your VSPackage DLL includes resources and the SatelliteDll\DllName registry entry points to it, Visual Studio attempts to load them in the above order.
See Also
Choosing Between Shared and Versioned VSPackages
Managing VSPackages
Managed Package Registration