编写出色的Visual Studio扩展的清单

To make it easier to write great extensions, we’ve worked with the extensibility community to come up with a simple checklist to follow. There’s even a GitHub issue template you can use so you remember to go through the checklist.

为了使编写出色的扩展更加容易，我们与可扩展性社区合作，提出了一个简单的清单。 您甚至可以使用GitHub问题模板 ，因此您记得要仔细检查清单。

规则 (Rules)

The following list is in no specific order. Remember to complete all items for best results.

以下列表没有特定顺序。 记住要完成所有项目以获得最佳结果。

规则1：遵守线程规则 (Rule 1: Adhere to threading rules)

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

将Microsoft.VisualStudio.SDK.Analyzers NuGet程序包添加到VSIX项目。 这将帮助您发现和修复有关线程的最佳实践的常见违规行为。

规则2：添加高质量图标 (Rule 2: 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 128×128 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. The Visual Studio Marketplace makes use of the larger icon and it will get resized dynamically when shown inside Visual Studio.

所有扩展名都应具有与其关联的图标。 确保图标是96 DPI或更高尺寸的128.128像素大小的高质量.png文件。 将图标添加到VSIX项目后，将其作为图标和预览图像注册到.vsixmanifest文件中。 Visual Studio Marketplace使用了较大的图标，当在Visual Studio中显示时，它将动态调整大小。

规则3：名称和说明 (Rule 3: Name and description)

Studies show that users are more likely to install extensions with short and descriptive names and accurate descriptions. Make sure the name reflects the essence of what the extension does. The description in the .vsixmanifest file should set expectations as to what the extension does. So, a brief mention of what problems it solves and what main features it has are key.

研究表明，用户更有可能安装带有简短描述性名称和准确描述的扩展程序。 确保名称反映了扩展名的本质。 .vsixmanifest文件中的描述应设置有关扩展名的期望。 因此，简要说明其解决的问题和主要功能是关键。

规则4：撰写良好的市场描述 (Rule 4: Write good Marketplace description)

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

这是使扩展成功的最重要的事情之一。 一个好的描述包括：

• Screenshots/animated GIFs of the UI added by the extension
  扩展程序添加的UI的屏幕截图/动画GIF
• Detailed description of the individual features
  各个功能的详细说明
• Links to more details if applicable
  链接到更多详细信息(如果适用)

规则5：添加许可证 (Rule 5: Add license)

The license is visible on the Marketplace, in the VSIX installer and in the Extensions Manager dialog. Always specify a license to set the expectations for the users. Consider using choosealicense.com to help find the right license for you. The reason for this rule is to remove any ambiguity, which is important for many Visual Studio users.

该许可证在Marketplace，VSIX安装程序和Extensions Manager对话框中可见。 始终指定许可证以设置对用户的期望。 考虑使用choicealicense.com帮助您找到合适的许可证。 该规则的原因是消除任何歧义，这对于许多Visual Studio用户而言很重要。

规则6：添加隐私声明 (Rule 6: Add privacy notice)

If the extension collects data such as telemetry or in any other way communicates with a remote endpoint, add a note about it in the description.

如果扩展名收集遥测等数据或以其他方式与远程端点通信，请在说明中添加有关此注释。

规则7：尽可能使用KnownMonikers (Rule 7: 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.

Visual Studio附带了数千个图标，可在KnownMonikers集合中使用。 将图标添加到命令按钮时，请查看是否可以使用现有的KnownMonikers图标，因为它们是Visual Studio用户熟悉的设计语言的一部分。 这是KnownMonikers的完整列表，并获取KnownMonikers Explorer扩展，以找到适合您的方案的扩展程序。

规则8：让VS具有原生感 (Rule 8: Make it feel native to VS)

Follow the same design patterns and principles that Visual Studio itself uses. This makes the extension feel natural to the users. It also reduces distractions caused by poorly designed UI. 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:

遵循Visual Studio本身使用的相同设计模式和原则。 这使扩展对于用户而言自然而然。 它还可以减少因UI设计不良而引起的干扰。 确保仅在用户处于正确的上下文中使用它们时，默认情况下才可见所有按钮，菜单，工具栏和工具窗口。 需要遵循一些经验法则：

• 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
  在不适用于它们的上下文中，任何按钮，菜单和工具栏都不应该可见

• If auto load is necessary (it probably isn’t), do it as late as possible.

  如果需要自动加载 (可能没有必要)，请尽早进行。

• Use VisibilityConstraints to toggle visibility of commands instead of relying on auto load

  使用VisibilityConstraints切换命令的可见性，而不是依靠自动加载

规则9：使用正确的版本范围 (Rule 9: 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.

一直支持从Visual Studio 2010开始一直支持Visual Studio版本，以确保每个人都可以使用您的新扩展。 这样做的问题是，这样做将无法再使用比扩展支持的最低版本晚的API。 这些新API通常很重要，有助于提高扩展以及Visual Studio本身的性能和可靠性。

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

以下是我们的建议，用于确定要支持的Visual Studio版本：

• Support only the previous and current version of Visual Studio – don’t support older versions if possible
  仅支持Visual Studio的先前版本和当前版本-如果可能，不支持旧版本

• Don’t specify an open-ended version range. E.g. [16.0,). Learn more about version ranges.

  不要指定开放式版本范围。 例如[16.0，)。 了解有关版本范围的更多信息。

你的想法 (Your thoughts)

What do you think of this checklist? Do you agree with the rules? Please let us know your thoughts in the comments below or on the GitHub repo for the checklist. I hope this makes it a little easier to give your extensions that little extra something that sets it apart from the rest.

您如何看待这份清单？ 您是否同意规则？ 请在下面的评论中或清单的GitHub存储库中告诉我们您的想法。 我希望这会使您的扩展程序少一点额外的东西，使其与众不同。

翻译自: https://habr.com/en/company/microsoft/blog/459824/