VSPackage Registration
VSPackages must advise Visual Studio that they are installed and should be loaded. This process is accomplished by writing information in the registry. That is a typical job of an installer.
Note
It is an accepted practice during VSPackage development to use self-registration. However, Visual Studio Industry Partner (VSIP) program partners cannot ship their products using self-registration as part of setup.
Registry entries in a Windows Installer package are generally made in the Registry table. You can also register file extensions in the Registry table. However, Windows Installer provides built-in support through the programmatic identifier (ProgId), class, extension, and verb tables. For more information, see Database Tables.
Be sure that your registry entries are associated with the component that is appropriate for your chosen side-by-side strategy. For example, registry entries for a shared file should be associated with that file's Windows Installer component. Likewise, registry entries for a version-specific file should be associated with that file's component. Otherwise, installing or uninstalling your VSPackage for one version of Visual Studio could break your VSPackage in other versions. For more information, see Supporting Multiple Versions of Visual Studio
Note
The easiest way to manage registration is to use the same data in the same files for both developer registration and install-time registration. For example, some installer-development tools can consume file in .reg-format at build time. If developers maintain .reg files for their own day-to-day development and debugging, those same files can be included in the installer automatically. If you cannot automatically share registration data, you must ensure that the installer's copy of the registration data is current.
Registering Unmanaged VSPackages
Unmanaged VSPackages (including those generated by the Visual Studio Package Template) use ATL-style .rgs files to store registration information. The .rgs file format is specific to ATL and cannot generally be consumed as-is by an installation authoring tool. Registration information for the VSPackage installer must be maintained separately. For example, developers can keep files in .reg format in sync with .rgs file changes. The .reg files can be merged with RegEdit for development work or consumed by an installer.
Registering Managed VSPackages
The RegPkg tool reads the registration attributes from a managed VSPackage and can either write the information directly to the registry or write .reg-format files that can be consumed by an installer.
Note
The RegPkg tool is not redistributable and cannot be used to register a VSPackage on a user's system.
Why VSPackages Should Not Self-Register at Install Time
Your VSPackage installers should not rely on self-registration. At first glance, keeping a VSPackage's registry values only in the VSPackage itself seems like a good idea. Given that developers need the registry values available for their routine work and testing, it makes sense to avoid maintaining a separate copy of the registry data in the installer. The installer can rely on the VSPackage itself to write registry values.
While good in theory, self-registration has several flaws that make it unsuitable for VSPackage installation:
Correctly supporting installation, uninstallation, installation rollback, and uninstallation rollback requires you to author four custom actions for every managed VSPackage that self-registers by calling RegPkg.
Your approach to side-by-side support might require that you author four custom actions that invoke RegSvr32 or RegPkg for every supported version of Visual Studio.
An installation with self-registered modules cannot be safely rolled back because there is no way of telling if the self-registered keys are used by another feature or application.
Self-registered DLLs sometimes link to auxiliary DLLs that are not present or are the wrong version. In contrast, Windows Installer can register DLLs using the registry tables with no dependency on the current state of the system.
Self-registration code can be denied access to network resources, such as type libraries, if a component is both specified as run-from-source and is listed in the SelfReg table. This can cause the installation of the component to fail during an administrative installation.