.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-party 组件（它们的发布时间与主要产品不同），您将采用这种方法。 但同样，如果您没有这个要求，我会说只是保持所有文件版本同步。

我看到的惯例是使用前 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

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

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

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

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

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

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

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

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

Answer 6

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