Update for Extension Authors: VSIX Manifest Version Range Attribute

Update for Extension Authors: VSIX Manifest Version Range Attribute

Rate This
  • Comments 5

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:

<InstallationTarget Id="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:

<InstallationTarget Id="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:

<InstallationTarget Id="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 Small

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.

Leave a Comment
  • Please add 7 and 2 and type the answer here:
  • Post
  • Maybe worth mentioning, that the version 1.0 schema (VS 2010), still works fine, and let you explicitly state each VS version you support.

  • Some extensions are also useful in products based on the VS isolated shell.  I'm thinking about source control extensions like Ankhsvn.  Would it be possible for authors to enable their extensions in any isolated shell without having to list them?

  • Wow, this must have been a really hard choice. It may result in a lot of unmaintained extensions simply not working on never versions of VS. Even for those that are maintained... what if the owner takes a couple weeks to realize that the extension is now blocked, and push an update? Seems risky for the users of extensions.

  • Man this is confusing. Please confirm the following:

    [11.0,12.0) - VS2012 only

    [11.0,12.0] - VS2012 and VS2013

    Is that correct?

    The phrase in the documentation, "The version range notation is [10.0 – 11.0]" is inconsistent with the examples which have a comma rather than a dash. What's up with that?

    What does "Single version #" mean? I can't find any examples containing a # character. Is # supposed to be shorthand for word "number"? If so, this is inconsistent with the example given later in the blog, "[12.0,]", shouldn't it be "[12.0]"?

  • @Bruce

    I would say yes, your first two assumptions are correct (at least thats how I understood the article).

    The phrase with the dash for the range is stated in MSDN for VS2012 and VS2013. But looking at examples throughout the Web, a comma is used.

    The "Single version #" (yes # is a placeholder for a number) would be Version="11.0" without any brackets and seems to be the same as Version="[11.0,]" (all versions beginning with 11.0).

Page 1 of 1 (5 items)