July 17, 2019 at 10:009 cool extension rules for Visual Studio
- 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.
Add the Microsoft.VisualStudio.SDK.Analyzers NuGet package to your VSIX project. This will help you identify and resolve common threading errors.
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.
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.
This is one of the most important things you must do to make your expansion a success. A good description consists of:
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.
If the extension collects data, such as telemetry, add a note about this in the description.
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.
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:
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:
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.
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.
rules
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.