Instantly share code, notes, and snippets.

Embed
What would you like to do?
VS extension checklist

Visual Studio Extensibility Checklist

Here is a list of things to make sure to remember before publishing your Visual Studio extension.

Adhere to best practices

Add the Microsoft.VisualStudio.SDK.Analyzers NuGet package to your VSIX project, which will help you discover and fix common violations of best practices

Add high-quality icon

All extensions should have an icon associated with it. Make sure the icon is a high-quality .png file with the size 128x128 pixels in 96 DPI or more. After adding the icon to your VSIX project, register it in the .vsixmanifest file as both the Icon and Preview image.

Add license

This license will be shown on the Marketplace, in the VSIX installer and in the Extensions and Updates... dialog. One should always be specified to set the expectations for the users. Use choosealicense.com to help find the right license for you.

Write good Marketplace description

This is one of the most important things you should do to make your extension successful. A good description consist of:

  • Screenshots/animated GIFs of the UI added by the extension
  • Detailed description of the individual features
  • Links to more details if applicable

Use KnownMonikers when possible

Visual Studio ships with thousands of icons which are available in the KnownMonikers collection. When adding icons to command buttons, see if you can use the existing KnownMonikers icons since they are part of a design language familiar to the Visual Studio users. Here's a full list of KnownMonikers and grab the KnownMonikers Explorer extension to find the right one for your scenarios.

Don't pollute Visual Studio

Make sure that all buttons, menus, toolbars and tool windows are only visible by default when the user is in the right context to use them. There are some rules of thumb to follow:

  • Don't ever add a new top level menu (next to File, Edit, etc.)
  • No buttons, menus and toolbars should be visible in contexts they don't apply to
  • Use VisibilityConstraints to toggle visibility of commands

Use proper version ranges

It can be tempting to support versions of Visual Studio all the way back to Visual Studio 2010 to ensure that everyone can use your new extension. The problem with that is that by doing so, it is no longer possible to use any APIs introduced later than that minimum version the extension supports. Often, those new APIs are important and help improve performance and reliability of both your extension as well as Visual Studio itself.

Here are our recommendations for deciding what versions of Visual Studio to support:

  • Support only the previous and current version of Visual Studio - don't support older versions if possible
  • Don't specify an open ended version range. E.g. [15.0,)

This is a template for a GitHub issue you can copy paste directly into a new issue on your own repo.

Follow the [Visual Studio Extensibility Checklist](https://gist.github.com/madskristensen/7310c0d61694e323f4deeb5a70f35fec) to ensure it meets the minimum requirements for a high-quality extension.

* [ ] Adhere to best practices
* [ ] Use high-quality icon
* [ ] Add license
* [ ] Write good Marketplace description
* [ ] Use KnownMonikers when possible
* [ ] Don't pollute Visual Studio
* [ ] Use proper version ranges
@SQL-MisterMagoo

This comment has been minimized.

Show comment
Hide comment
@SQL-MisterMagoo

SQL-MisterMagoo May 4, 2018

"Show in Help/About" - is there something equivalent for MEF editor extensions - where there is no Package?

SQL-MisterMagoo commented May 4, 2018

"Show in Help/About" - is there something equivalent for MEF editor extensions - where there is no Package?

@madskristensen

This comment has been minimized.

Show comment
Hide comment
@madskristensen

madskristensen May 4, 2018

There is not. Just add a package class to the MEF project

Owner

madskristensen commented May 4, 2018

There is not. Just add a package class to the MEF project

@justcla

This comment has been minimized.

Show comment
Hide comment
@justcla

justcla Jun 12, 2018

Add a ReleaseNotes.txt or, better yet, link to a ReleaseNotes / Readme on GitHub.

justcla commented Jun 12, 2018

Add a ReleaseNotes.txt or, better yet, link to a ReleaseNotes / Readme on GitHub.

@sitwalkstand

This comment has been minimized.

Show comment
Hide comment
@sitwalkstand

sitwalkstand Jul 20, 2018

Something that would be helpful would be to know that if you use Newtonsoft.Json, that all versions are suppressed. Version 9.0.1 is included in VS2017, but if I reference a newer version it is suppressed when the VSIX is built. The error "file cannot be found" when I run the extension is technically accurate, but there isn't any warning or information that the assembly will be suppressed when building my extension.

sitwalkstand commented Jul 20, 2018

Something that would be helpful would be to know that if you use Newtonsoft.Json, that all versions are suppressed. Version 9.0.1 is included in VS2017, but if I reference a newer version it is suppressed when the VSIX is built. The error "file cannot be found" when I run the extension is technically accurate, but there isn't any warning or information that the assembly will be suppressed when building my extension.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment