VSIX最佳实践

Visual Studio博客

2010年6月9日01

这篇文章是关于在VS2010中引入的一种新的VisualStudio扩展安装方法，称为VSIX文件。它所包含的信息对于开发VisualStudio扩展的读者来说是最感兴趣的，但我鼓励下载并安装这些扩展的用户也阅读它。

VSIX文件符合ECMA Open Packaging Conventions（OPC）标准。它是作为Visual Studio中VSIX项目构建的一部分创建的，您可以使用任何zip文件实用工具查看其内容。如果您将VSIX上传到Visual Studio库，您的客户可以直接在Visual Studio中安装扩展管理器以下为：

也可以通过下载并双击文件来安装它，然后在扩展管理器中卸载，或者只需删除相关文件即可。您可以找到有关VSIX的介绍信息在这里和在这里.

VSIX功能有很多选项。在大多数情况下，你不必完全理解它们。这篇文章是一系列提示，将为您提供如何以最佳方式使用新VSIX功能的一些指导。我要谈的是：

如何以最简单的方式将扩展打包到VSIX中
如果需要，如何通过MSI安装
如何使用VSIX版本控制
应该避免什么

使用VSIX打包扩展

使用强名称为你们所有的集会。您不希望您的“util.dll”与其他人的“util.dll”冲突；如果不使用强名称，系统将无法区分它们，并且有人会收到运行时错误。
在一个独立的VSIX中分发整个产品如果可以的话。该功能确实允许一个VSIX依赖于另一个。但是，如果每个VSIX都是单独开发和发布的，那么就不用考虑了，因为发布单个VSIX将减少您必须了解的信息量。
如果您提供多个VSIX，并且它们共享公共程序集，将公共程序集复制到每个单独的VSIX中。这样可以在上面描述的一个VSIX中运送整个产品。运送通用程序集的副本不会对运行时造成任何伤害–在内存中，CLR只会加载一个：但请注意，它只加载一个，第一个加载的将获胜。因此，您应该将更新发送到所有包含公共程序集的VSIX。
如果您的产品正在扩展另一个扩展，则您的VSIX需要使用下面对话框中的选择已安装扩展或手动引用选项（通过单击VSIX清单编辑器中的添加引用按钮来提出）来依赖目标VSIX。在这种情况下
- 阅读下面的版本控制部分，了解在此对话框中指定目标VSIX版本的最佳方法。
- 注意您的目标扩展的更新，并进行测试以确保您的扩展仍然与每个更新兼容。
如果您的VSIX发布了另一个VSIX将使用的API
- 阅读下面的版本控制部分，了解您的用户期望您的版本控制行为如何。
- 维护二进制兼容性如果可以的话，在不同版本之间；这只会让你的扩展器的生活更简单。
- 让扩展器了解即将到来的更新，以便他们可以对其进行测试。如果您计划发布破坏兼容性的版本，请确保他们提前知道。

通过MSI安装

一些扩展仍然需要由MSI安装：例如，您的一些文件可能必须位于特定的、众所周知的位置tion，您可能有一个组件，如VSIX安装不支持的MSBuild任务，您可能需要使用绑定重定向–查看更多信息在这里。这样做没有问题。事实上，我们为MSI安装的扩展提供了一种方法，使其在新的扩展管理器中可见，以便客户可以在一个位置看到其所有扩展。

要使扩展在extension Manager中可见，MSI安装应在Extensions目录中为宿主产品创建一个子目录：

对于Visual Studio中的非管理性用户安装（推荐），路径如下所示：用户用户idAppDataLocalMicrosoftVisualStudio10.0扩展您的公司扩展名版本对于每台机器的安装：程序文件VS 10.0安装目录Common7Ide扩展您的公司您的扩展名版本独立Shell应用程序将定义自己的Extension目录。

在该文件夹中，放置由VSIX项目构建的extension.vsixmanifest文件，并添加一个元素，将其标记为MSI已安装：

<标识符Id=“VSIXProject2.Microsoft IT.8532242f-afdc-44fa-82b2-0b6b5afc1c38”><Name>VSIXProject2</Name><InstalledByMsi>true

…</标识符>

请注意，尽管用户随后会在扩展管理器中看到该扩展，但由于它是由MSI安装的，他仍然需要通过Windows添加/删除程序来管理它。

版本控制

如果您的扩展是自包含的（即，您将其分发到一个单独的VSIX中，该VSIX与其他VSIX没有任何依赖关系），并且没有其他VSIXs将依赖于您的扩展（即，VSIX不公开任何API），则无需阅读本节。如果您的VSIX确实提供或使用API，或者您使用公共共享程序集分发多个VSIX，请继续阅读以获取更多信息。

首先，让我们快速回顾一下CLR中版本控制的工作原理。对于具有强名称，其CLR标识来自磁盘上文件名的组合，程序集版本字符串、可选的文化属性和数字签名。当一个程序集引用（即从另一个程序集中使用API）另一个时，使用者将在构建时以被引用程序集的特定版本为目标。(绑定重定向可以在运行时更改此设置，但VSIX安装程序尚不支持。）版本字符串包含四个段：<主要版本><次要版本><内部版本号><修订版>（例如“1.2.123.0”）。建议使用版本字符串的约定是，当程序集的API中断时二进制兼容性，主版本递增。（请注意，我指的是程序集版本，它是强名称的一部分，不程序集文件版本，这纯粹是信息性的——您可以以任何方式使用程序集文件版本。查看更多信息在这里.)

这些都是背景信息。现在，让我们讨论如何对VSIX文件使用版本控制。尽管听起来可能有点出乎意料，但我要推荐的第一件事是你不在发布VSIX更新时更改Assembly Version字符串。这是因为，正如我前面提到的，VSIX安装程序尚不支持绑定重定向，因此如果您更改了程序集版本号的任何段，则可能会中断依赖于程序集旧版本号的下游VSIX。VSIX文件有自己的版本管理机制，我建议您使用该机制，因为它增加了灵活性，可以解决绑定重定向问题。

对于使用另一个VSIX的API的VSIX：

VSIX版本字符串的语法与程序集字符串的语法相同，我们将使用推荐的约定来指示新版本打破了与旧版本的二进制兼容性：增加主版本号。VSIX版本控制机制的最大优点是，如果您正在使用另一个VSIX的API，那么可以指定与之兼容的目标VSIX一系列版本号。让我们看看这是如何工作的。在VSIX清单编辑器中引发“添加VSIX引用”对话框时：

在上面的版本字段中，可以指定兼容的最小和最大版本号之间的范围。如果您使用其API的VSIX开发人员遵守版本控制约定，您可以指定一个类似于Min 1.0到Max 1.9999的范围，以表示您将在这两者之间使用依赖关系的任何版本。当您所依赖的VSIX安装时，例如1.2版，您将与它兼容。当用户尝试安装2.0时，安装程序将识别出不兼容：