9 rules cool extension for Visual Studio
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 need to perfection and natively fit into the internal functions of Visual Studio.
To make it easier to write good extensions, 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 consider the 9 rules of a steep extension. Details under the cut.
')
The following list has no order. Remember to follow all the rules for best results.
Add the NuGet Microsoft.VisualStudio.SDK.Analyzers package to your VSIX project. This will help you detect and fix common errors with respect to threads.
All extensions must have an icon associated with them. Ensure that the icon is a high-quality .png file with a resolution of 128 × 128 pixels and DPI 96 or more. After adding the badge 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 often install extensions with short descriptive names and accurate data about them. Make sure that the name reflects the essence of what the extension does. The description in the .vsixmanifest file should create expectations about what the extension does. In summary, a brief description of which problems the extension solves and which of its functions are key.
This is one of the most important things you must do to make your expansion successful. 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 choosing choose your customer.com to find a suitable license. The reason for this rule is to eliminate any ambiguity, which is important for many Visual Studio users.
If an 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: perhaps you can use existing icons of KnownMonikers, because they are part of a design language familiar to users of Visual Studio. Here is a complete list of KnownMonikers , and you can also use the KnownMonikers Explorer extension to find the right one for your scripts.
Follow the same design patterns and principles that Visual Studio itself uses. This makes the extension natural for users. It also reduces distractions caused by a poorly crafted 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 a few rules:
It may be tempting to support versions of Visual Studio right up to Visual Studio 2010 so that everyone can use your new extension. The problem is that you can no longer use the API presented 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 recommendations for deciding which versions of Visual Studio to support:
What do you think about 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 will help you create cool extensions that will become really popular.
To make it easier to write good extensions, 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 consider the 9 rules of a steep extension. Details under the cut.
')
rules
The following list has no order. Remember to follow all the rules for best results.
Rule 1: Follow the rules of ballot copying.
Add the NuGet Microsoft.VisualStudio.SDK.Analyzers package to your VSIX project. This will help you detect and fix common errors with respect to threads.
Rule 2: Add an icon in high quality.
All extensions must have an icon associated with them. Ensure that the icon is a high-quality .png file with a resolution of 128 × 128 pixels and DPI 96 or more. After adding the badge 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 often install extensions with short descriptive names and accurate data about them. Make sure that the name reflects the essence of what the extension does. The description in the .vsixmanifest file should create expectations about what the extension does. In summary, a brief description of which problems the extension solves and which of 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 successful. A good description consists of:
- Screenshots / GIFs of what will be added by the extension
- Detailed description of features
- Links to parts, if necessary
Rule 5: Specify 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 choosing choose your customer.com to find a suitable license. The reason for this rule is to eliminate any ambiguity, which is important for many Visual Studio users.
Rule 6: Add a privacy notice.
If an 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: perhaps you can use existing icons of KnownMonikers, because they are part of a design language familiar to users of Visual Studio. Here is a complete list of KnownMonikers , and you can also use the KnownMonikers Explorer extension to find the right one for your scripts.
Rule 8: Create a sense of native expansion
Follow the same design patterns and principles that Visual Studio itself uses. This makes the extension natural for users. It also reduces distractions caused by a poorly crafted 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 a few 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 autoloading is necessary (most likely not), make it as late as possible.
- Use VisibilityConstraints to switch the visibility of commands instead of relying on automatic loading.
Rule 9: Use the correct version ranges.
It may be tempting to support versions of Visual Studio right up to Visual Studio 2010 so that everyone can use your new extension. The problem is that you can no longer use the API presented 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 recommendations 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 a range of available versions. For example. [16.0,). Learn more about the versions here .
Your opinion
What do you think about 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 will help you create cool extensions that will become really popular.
Source: https://habr.com/ru/post/459832/
All Articles