9 cool extension rules for Visual Studio

Original author: Mads Kristensen
  • Transfer
Cool Visual Studio extensions have several key features that distinguish them from the rest. They look and are actually well thought out, functional and reliable. In addition, they do what they should, to the level of excellence and natively fit into the internal functions of Visual Studio.

To make writing good extensions easier, we are working with the community to develop a simple checklist. There is even a  GitHub issue template that you can use. In this article, we’ll look at 9 cool expansion rules. Details under the cut.


The following list is not in order. Remember to follow all the rules for best results.

Rule 1: Adhere to the rules of coverage

Add the Microsoft.VisualStudio.SDK.Analyzers NuGet package to your VSIX project. This will help you identify and resolve common threading errors.

Rule 2: Add High Quality Icon

All extensions must have an icon associated with them. Make sure the icon is a high-quality .png file with a resolution of 128 × 128 pixels and a DPI of 96 or more. After adding the icon to the VSIX project, register it in the .vsixmanifest file as an icon and a preview image. The Visual Studio Marketplace uses a larger icon and yours will dynamically change when displayed in Visual Studio.

Rule 3: Title and Description

Studies show that users more often install extensions with short descriptive names and precise information about them. Make sure the name captures the essence of what the extension does. The description in the .vsixmanifest file should create expectations about what the extension does. In total, a brief description of what problems the extension solves and what its functions are key.

Rule 4: Write a Good Marketplace Description

This is one of the most important things you must do to make your expansion a success. A good description consists of:

  • Screenshots / GIFs of what will be added by the extension
  • Detailed features description
  • Links to details, if necessary

Rule 5: Indicate the license

The license is displayed in the Marketplace, in the VSIX installer, and in the Extensions Manager dialog box. Always specify a license to create expectations for users. Consider using  choosealicense.com to find the right license. The reason for this rule is to resolve any ambiguity, which is important for many Visual Studio users.

Rule 6: Add a privacy notice

If the extension collects data, such as telemetry, add a note about this in the description.

Rule 7: Use KnownMonikers Where Possible

Visual Studio comes with thousands of icons that are available in the KnownMonikers collection  . When adding icons to buttons, check: maybe you can use existing KnownMonikers icons, because they are part of the design language familiar to Visual Studio users. Here is a complete list of KnownMonikers , and you can also use the KnownMonikers Explorer extension to find the one that suits your scripts.

Rule 8: Create a sense of native extension

Follow the same patterns and design principles that Visual Studio itself uses. This makes the extension natural for users. It also reduces distractions caused by a poorly designed user interface. Make sure that all buttons, menus, toolbars, and tool windows are visible by default only when the user is in the right context for using them. There are several rules:

  • Never add a new top-level menu (next to File, Edit, etc.)
  • No buttons, menus, or toolbars should be visible in contexts to which they do not belong.
  • If you need  autoload (most likely not), do it as soon as possible.
  • Use VisibilityConstraints  to toggle command visibility instead of relying on automatic loading

Rule 9: Use the correct version ranges

It may be tempting to support versions of Visual Studio up to Visual Studio 2010 so that everyone can use your new extension. The problem is that you can no longer use the APIs introduced later than the old version that the extension supports. Often these new APIs are important and help improve the performance and reliability of both your extension and Visual Studio itself.

Here are our guidelines for deciding which versions of Visual Studio to support:

  • Support only previous and current versions of Visual Studio - if possible, do not support older versions
  • Do not specify the range of available versions. For instance. [16.0,). Find out more about the  versions here .

Your opinion

What do you think of this checklist? Do you agree with the rules? Please share your thoughts below in the comments or in  the GitHub repository . I hope the checklist helps you create cool extensions that will become really popular.

Also popular now: