c# - .net：DLL 与 EXE 的版本号？

Question

我最近一直在对我的产品 (exe) 进行版本控制，并且每次都在 assemblyinfo.cs 中增加内部版本号。

效果很好，我的产品目前是 1.5.xx 版本，所以每次成功构建时增加 4 位数。

现在我有了我的 DLL，它们也是我的应用程序的一部分。

我怎么能对这些进行版本控制？我应该将这些版本与我的 exe 相同，即 1.5.xx 还是应该创建另一个不同的版本号？

这是我目前有点困惑的地方。

当我的产品功能增加时，我可以将 1.5 提高到 2.0，但这会将我的 DLL 放在哪里？

Answer 1

您可能会得到多种意见，但我会说保持简单并让 EXE 和 DLL 版本保持同步。如果您真的打算独立发布 DLL 和 EXE 的版本，我可能会改变我的看法，但您没有提到这是一项要求。如果您将某些文件处理为 3rd 方组件（与主要产品的发布时间不同），您将采用这种方法。但同样，如果您没有此要求，我会说只是保持所有文件版本同步。

我见过的很好的约定是使用前 3 个数字来表示产品版本（主要/次要等），版本号的第 4 部分表示源代码控制版本（这样您就可以确切地知道二进制文件的哪些源文件来自）。

希望有帮助，

约翰

Answer 2

在我看来，您应该只有一个在应用程序中共享的 assemblyinfo 文件。这样就很容易维护它。当然，这意味着您的所有程序集都有一个版本，这对我来说是可以接受的规范。参考这个。

Answer 3

在我看来，您必须单独管理它们的版本。

因为 2 个应用程序（EXE）可以使用同一个 DLL。DLL 将是什么版本？

DLL 的版本应该独立于运行它的 EXE。

Answer 4

从另一面看 - 为什么需要版本号？例如，一个答案可以是知道在某些客户端位置部署了什么。

因此，如果您有部署为主 exe 和一些 dll 的应用程序，并且此 dll 不是任何其他应用程序的一部分，即使您完全忘记了 dll 版本控制，您也可以感到安全。

否则，如果 dll 将成为多个项目的一部分，请将其版本增加到您认为合乎逻辑的任何方案，例如，当您添加一些功能或更改相当大的内容时，增加 MINOR 1.X.0.0，如果您有，请增加 MAJOR里面完全不同的类，...

至于因为功能而增加 MAJOR，当然又是个人品味，我建议如下：

• 如果添加了功能，则增加 MINOR，并达到一些重要的里程碑
• 如果您更改用户界面范例，则增加 MAJOR，这表明您进行了一些重大的重新设计或重写。

另外：版本语法解释？

Answer 5

简单的答案是在您进行更改时增加版本号。不要让 EXE 和 DLL 保持同步，因为它们没有理由保持同步。DLL 旨在实现可移植性——理论上任何 EXE 都可以使用它。如果您已有 DLL 的版本号，则将其用作当前基准，并在修改它时根据需要增加版本号。

Answer 6

你触及了一个非常大的话题，它真的可以变得尽可能复杂。

最终，您选择的版本控制方法将取决于您需要实现什么，以及您必须分配多少时间来维护它。两者直接相关。

版本控制的两个主要目标是并行执行和跟踪。并行 (SxS) 允许同一 DLL 的多个版本在同一应用程序中执行。如果不更改程序集版本号，这是不可能的。跟踪只是能够确定在客户机器上运行的确切代码快照。两者都可以通过更改程序集版本来实现，但第一个只能通过更改程序集版本来实现。

许多人会建议您在所有 DLL/EXE 中共享版本号 - 这是一个很好的方法，因为它是最简单的方法，它也实现了最小的部署灵活性。

例如，如果您使用任何形式的契约抽象（通过接口而不是具体类型定义 DLL 之间的依赖关系），您可能会将应用程序拆分为多个“版本控制孤岛”。这方面的一个例子是客户端和服务器，如果在第三个程序集中定义了相互依赖关系，那么您的 WCF 合同。如果它们都是单独版本的，那么你可以发布一个新版本的服务器（只要它符合相同的合同），而不影响客户端。反之亦然。

如您所见，随着需求的增长，您将增加版本控制粒度，但这会导致无意中听到。

你能做的最好的事情就是你正在做的事情，坐下来计划你的需求，然后绘制你的版本控制边界（哪些组件可以通过合同分开）。

接下来的事情取决于您的测试部门的规模，但我也建议您查看文件版本（至少部分反映）内部版本号/日期。对于每个客户版本，您只会增加一次程序集版本，但是对于生成的每个 DLL 集合，您应该有一个不同的文件版本。这是因为当您进行测试并找到问题时，让这些 DLL 具有唯一可识别性将消除关于 DLL 究竟源自哪个构建的任何疑问。