.net：DLL vs EXE的版本号？

Question

我最近一直在版本化我的产品（exe）并每次在assemblyinfo.cs中增加内部版本号。

效果很好，我的产品目前是1.5.x.x版本，因此每次成功构建时都会增加4位数。

现在我的DLL也是我的应用程序的一部分。

有什么人会建议如何对这些进行版本化？我应该将这些版本与我的exe版本相同，即1.5.x.x，还是应该创建另一个不同的版本号？

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

当我的产品功能增加时，我可以提高1.5到2.0，但这会留下我的dll？

非常感谢任何关于版本控制的建议

感谢

Answer 1

你可能会得到多个意见，但我会说保持简单并让EXE和DLL版本保持同步。如果您真的打算独立发布DLL和EXE的版本，我可能会改变我的观点，但您没有提到它作为一项要求。如果您正在处理某些文件（如第三方组件（以与主产品不同的时间表发布），则可以使用此方法。但同样，如果你没有这个要求，我会说保持所有文件版本同步。

我见过的常规工作是使用前3个数字来表示产品版本（主要/次要等...），版本号的第4部分代表源代码控制版本（所以你确切知道哪个来源二进制来自的文件。）

希望有所帮助，

约翰

Answer 2

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

Answer 3

在我看来，你必须分开管理他们的版本。

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

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

Answer 4

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

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

否则，如果dll将成为多个项目的一部分，请将它们的版本增加到对您来说合乎逻辑的ANY方案，例如，当您添加某些功能或更改相当大的内容时增加MINOR 1.X.0.0，增加MAJOR如果你里面有完全不同的课程，......

至于由于功能而增加MAJOR，当然这又是个人品味，我建议有类似的东西：

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

另外：Version Syntax Explanation?

Answer 5

你已经触及了一个非常大的主题，它实际上可以变得像你允许的那样复杂。

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

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

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

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

正如您所看到的，随着需求的增长，您将增加版本控制粒度，但会听到它。

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

接下来的事情取决于测试部门的大小，但我还建议您查看文件版本（至少部分）反映内部版本号/日期。 每个客户版本只会增加一次程序集版本，但是对于从构建中发出的每个DLL集合，您应该有一个不同的文件版本。这是因为当您进行测试并找到问题时，将这些DLL唯一标识可以消除对DLL源自哪个版本的确切疑问。

Answer 6

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