When creating a Visual Studio add-in, you had full control of the full name of its commands (command prefix + command short name, such as “MyAddIn.MyCommand”), as I explained in the article HOWTO: Create command names without ‘.Connect’ in Visual Studio add-ins. So, when I created my MZ-Tools add-in for Visual Studio, each version used a command prefix such as “MZTools6” or “MZTools7”, and I could provide that information to the end user to customize the keyboard shortcuts, for example:

Another nice consequence was that, given a Visual Studio version, two versions of the add-in (for example one purchased, next one evaluating) could be loaded at the same time without collisions of add-in command full names, because each one used a different command prefix.

With packages, you lack the control over the command prefix, as I explained in INFO: How a Visual Studio package command is named. So, the commands of a package cannot be named “MyPackage.MyCommand”. And it is perfectly possible that two packages (or two versions of the same package loaded side by side) create two commands with the same full name as in this example:

This is possible because Visual Studio commands (as everything else in Visual Studio) are identified by Guids and Ids and not by names (the EnvDTE.Command interface exposes those two properties).

Therefore, given that a collision of command full names is not really a collision internally in Visual Studio (only in the user interface level), so far so good. But if your add-in assumes that its commands have unique full names (because the command prefix is unique for add-ins) and uses code like this:

EnvDTE.Command command = dte.Commands.Item("MyAddIn.MyCommand");

that will cause problems when migrating to a package:

EnvDTE.Command command = dte.Commands.Item("Tools.MyCommand");

You see, the command full name now uses “Tools” (for example) instead of “MyAddIn”. If you have two versions of your package loaded side by side, that call can return the command of the wrong package version. A similar problem to getting the correct CommandBar as explained in HOWTO: Get a CommandBar by Guid and Id rather than by name from a Visual Studio add-in.

The same can happen if you execute a command by name:

dte.ExecuteCommand("Tools.MyCommand");

The solution is to stop using command full names in the code to identify commands, and to use the command Guid / Id instead:

• To locate a command, the EnvDTE.Commands.Item method can accept not only a command full name, but also a command guid and a command id.
• To execute a command, you can use the automation way (HOWTO: Execute a command by Guid and Id from a Visual Studio add-in) or the package way (HOWTO: Execute a command by Guid and Id from a Visual Studio package).

In my MZ-Tools extension I use a lot of command stuff, so I have to review/change several areas of the product as part of the migration to a package. Also, the user can create commands for each code template of the Code Library feature (notice the optional Command Name field):

In the code of the add-in, that is done using the EnvDTE80.Commands2.AddNamedCommand2 method. Although you can use automation (EnvDTE) from a package, you can’t use that method because its first parameter is of the type EnvDTE.AddIn. I guess that a package must use the AddNamedCommand methods of the IVsProfferCommands interface. I will post and provide a sample once I try it.

I am these days porting my MZ-Tools add-in to a package, and as every other developer of extensions I would like to target several different Visual Studio versions (say 2010, 2012 and 2013 and “14”) with:

1. The same project file (MyAssembly.csproj)
2. The same binary assembly (MyAssembly.dll)
3. The same setup (MyAssembly.vsix or MyAssemblySetup.exe)

About #1, you need to learn something about MSBuild but is doable. In my case I just want to use VS 2013 always and changing something in the .csproj file I can deploy and debug selectively to VS 2010, 2012 or 2013 experimental instances. But if you want to change nothing, you can open the same .csproj file in different VS versions and deploy and debug for that VS version as Daniel Cazzulino explained in his post How to create a Visual Studio extensibility project that is compatible with VS 2010, 2012 and 2013. Jared Parsons has also explained about Round Tripping a VSIX project.

About #2, if you stick to the assemblies provided by VS 2010 that are also supplied by higher VS versions it is doable too. I have used that approach for MZ-Tools being an add-in for years, as I explained in the article HOWTO: Create an add-in that targets several Visual Studio versions with the same add-in DLL using C# or VB.NET.

About #3, .vsix files already have support for several Visual Studio versions specified in the manifest. And if you create your own setup (MSI or otherwise) you have full control of the deployment.