First of all, the doctor apologizes if he has misdirected some of you with his earlier post on this topic. I realized that there were major discrepancies in the approach that I had recommended. I have removed the earlier post since and am reposting the topic with required changes. I deeply apologize for any inconvenience caused. If you had referenced the previous post in your blogs Please update it to point to this one. The previous one will now link to this post.
Deploying Visual Studio 2003 managed VSPackages
Prior to the release of VSIP Extras, VSIP developers only had unmanaged code interfaces based on COM to extend the Visual Studio .NET IDE. With the new features of VSIP Extras, developers are able to write managed VS packages. So, how do you deploy a managed package on a separate machine without VSIP Extras? This article focuses on clarifying the procedure and some key things to keep in mind.
The following section assumes that you have embedded a Package Load Key (PLK) in your package. To request a PLK, go to http://www.vsipdev.com/plkregister.aspx
For managed VSPackages the following need to be deployed to enable integrating with Visual Studio 2002 or Visual Studio 2003:
§ VSIP Interop Assemblies
§ Your Package binaries
VSIP Extras for 2003 ships a redistributable for VSIP Interop assemblies VSIP Interop Assembly Redist.msi that installs the following VSIP interop assemblies. These assemblies are installed in the Global Assembly Cache (GAC). This redistributable is located in VSIP SDK installation folder under the EnvSDK directory. It is highly recommended that you use MSI to deploy your packages.
Interop Assembly Name
Provides access to some standard OLE interfaces.
Provides access to basic environment (shell) interfaces.
Provides access to core editor interfaces.
The Microsoft.VisualStudio.VSIP.Helper.dll, managed helper classes, provides a higher level of abstraction, utility classes and error handling. These classes use the interop assemblies to access the VSIP COM interfaces. This helper assembly is installed for the VSIP developer by the VSIP Extras installation and is located under <EnvSDK>\common\VSIA folder. If you have modified/customized Microsoft.VisualStudio.VSIP.Helper sources you should rename, resign/strong name the Helper assembly to have your company's identity (e.g.Acme.VisualStudio.VSIP.Helper.dll signed with your strong name key). Use these rebuilt binaries to ship with your package instead of the one that get installed by the VSIP 2003 Extras installation. It is highly recommended that you install your binaries in your company specific folder. For example Acme Inc.’s editor package can be installed under Program Files\Acme Inc Editor. This is irrespective of the fact if you customized the Microsoft’s helper classes or not. In fact I would go as far as saying as this is a requirement for the following reason. This approach helps isolate your packages from accidentally uninstalling or overwriting third partner’s copy of the Microsoft helper classes. In Visual Studio 2005 we are working on having Microsoft helper classes installed in known folder so partners don’t have to ship it. If you have customized the helper classes you should consider that to be an assembly private to your product and hence install it under your Company’s installation folder.
You have freedom to put your binaries any where you wish however make sure that Visual Studio is able to find them when it attempts to load. The choices there are:
1. Global Assembly Cache. This requires that your assemblies be strong named.
2. Visual Studio Private Assemblies folder. Put assemblies here only if your assemblies are unique to your product. Do not do this unless it is absolutely required.
3. Your custom installation path. This requires that you register your package with a /codebase option. This is the preferred choice.
A typical managed VSPackage deployment would do the following:
Run VSIP Interop Assembly Redist.msi to install the VSIP IAs on the machine you want to deploy on.
Run <Your Company Package>.msi to install your product binaries and helper classes to a location specific to your company. Make sure both the VSPackage assembly and its satellite DLL are copied to the machine, and the satellite DLL resides in an appropriate locale subfolder (e.g., 1033 for ENU) of the VSPackage assembly. The installation should also register the managed VSPackage using a reg file that is generated by the VSIP VSPackage registration utility (VSIPRegPkg.exe /regfile option). If you have customized Helper classes then you should also rebuild VSIPRegPkg.exe using your Helper assembly. If you are not using the Helper classes and directly implementing the interfaces then you need to create your own registration scripts (.reg file) and use them instead. The section below applies only if you are relying on VSIP Helper assembly. VSIPRegPkg can be found at <EnvSDK>\tools\bin\x86\ folder.
1. Make sure the correct registration attributes are added to the source file that implements Package. Following is an example in C#:
[VSIP.Helper.InstalledProductRegistration(ProductNameResId=100, ProductDetailsResId = 102, IconResId = 400, ProductId = "1.0")]
For the detailed use of different registration attributes, see
2. Run VSIPRegPkg.exe to generate the registration script for registering your VSPackage assembly. To install the VSPackage assembly into its default registry root based on the attribute applied to the Package derived class. For e.g:
‘VSIPRegPkg.exe /regfile:AcmePacakgeReg.reg AcmeVsPackage.dll‘
Use the generated reg file to register on client machine.
To install the assembly into a specific registry root:
/root:<custom_root> /regfile:AcmePacakgeReg.reg AcmeVsPackage.dll
In place of <root>, type the fully qualified registry root in which you wish to install the VSPackage, for example, Software\Microsoft\VisualStudio\7.1Exp.
You could also use the /regfile or /vrgfile options to generate static registration scripts. However a word of caution using these options, the path that is generated for InProcServer32 value points to mscoree.dll in System32 folder under the %WinDir%. So the registration script can have path that need not match the target operating system’s %WinDir%.
3. Run ‘devenv /setup /rootsuffix Exp’ at the Windows command prompt. The command merges command bars and other UI item changes.