In Visual Studio 2010 we introduced a new deployment model for extensions, the VSIX format. This format is based on the Open Packaging Conventions and enables extension developers to create a single package that can be easily installed by Visual Studio and contain all the appropriate files to describe the extension.

For Visual Studio 2012 we wanted to add additional functionality to how we can manage the deployment process for extensions so we updated the VSIX Schema to version 2.0. This schema enabled us to support the concept of extension and platform SDKs that provide library functionality for tooling on specific platforms.

We’re pretty happy with how this turned out in Visual Studio 2012 but we have to admit that we found some issues with how versioning is handled in this schema.

In VS 2012 when you create an extension project we default to creating:

<InstallationTargetId="Microsoft.VisualStudio.Pro" Version="11.0" />

The template we’re using here has defaulted to setting the installation target to be Version=”11.0”. No real problem here right? I’m targeting Visual Studio 2012 which is version 11 so I’m all good. Actually no, version=”11.0” looks like it says 11.0 only but it doesn’t really.

From the existing version 2.0 schema:

o Version – This attribute specifies a version range with the minimum and maximum supported versions of this SKU. A package can detail the versions of the SKUs that it supports. The version range notation is [10.0 – 11.0], where:

• [ - minimum version inclusive.
• ] – maximum version inclusive.
• ( - minimum version exclusive.
• ) – maximum version exclusive.
• Single version # - minimum supported version with unbounded max.

If you look closely, what version=”11.0” is really saying is that this extension will run on version 11.0 and every version of Visual Studio after that. That’s certainly not what I want because I can’t guarantee that my extension will run on every version of Visual Studio.

For Visual Studio 2013 we took the hard choice to change the schema. From 2013 onwards a single version # will specifically mean that version. Actually we use the format A.B.X.Y for our version numbers so it means from “A.B.0.0” to “A.B.[int.MaxValue].[int.MaxValue]”. In general we haven’t been incrementing ‘B’ for VS Updates but if you want to be absolutely sure that you’ll support anything in the ‘A’ version, you can say:

<InstallationTargetId="Microsoft.VisualStudio.Pro" Version="[12.0,13.0)" />

If you want to create something that does support the current version and every version in the future (for example if you were creating a sample you might want it to move forward regardless) then you can say:

<InstallationTargetId="Microsoft.VisualStudio.Pro" Version="[12.0,]" />

If you’re writing the extension you have control over this but what is going to happen to the Visual Studio Gallery? Our Gallery team has updated how they generate the VSIX manifests for samples so you’ll still have the unbound max expectation for samples. For extensions they have gone back in and reread the VSIX manifest to recreate the extension metadata in their database (they don’t scan the manifests every time you hit the Extensions & Updates dialog, instead they store it in a database field) and set a min and max version of 11.0 for those Visual Studio 2012 extensions that say version=”11.0”.

So what should I do?

Because the version range support works for both Visual Studio 2012 and Visual Studio 2013 we recommend that you update your extension manifest file to specifically state what versions you support and then release that updated version to the Visual Studio Gallery.

This means if you have published an extension on the Gallery and you want to support multiple VS versions you should update your version item to reflect the range you want and then upload that new version to the Gallery. If you want the unbound max experience you’ll need to use a version statement like the one above.

Overall we think that this will give you a better extension and Gallery experience because the developer of the extension has deliberately given the versions they want to support.

Tony Goodhew – Program Manager, Visual Studio IDE Services After the better part of 19 years spent in Visual Studio (and precursor tools) Marketing, Tony decided that he should either make a career of it or try something new. He joined the IDE Services team as a Program Manager in early 2012 and has been working on Visual Studio extensibility and the Visual Studio Industry Partner Program since then. While not known for enjoying pina coladas and getting caught in the rain, his version of paradise would include a cheeseburger.