我最近对我的产品（exe）进行了版本控制，并在assemblyinfo.cs中每次增加构建号。这很好用，我的产品目前是1.5.x.x版本，所以每次成功构建后我都会增加4位数字。现在我有了我的DLL文件，它们也是我的应用程序的一部分。我应该如何为它们命名版本号？我应该像我的exe一样将它们命名为1.5.x.x，还是应该创建另一个不同的版本号？这就是我目前有点困惑的地方。当我的产品功能增强时，我可以将1.5提高到2.0，但这会让我的DLL文件怎么办？
6个回答
2
你可能会得到多种意见，但我认为保持简单并确保EXE和DLL版本保持同步是比较好的做法。如果你真的打算独立发布DLL和EXE的版本，那么我可能会改变我的意见，但你没有提到这一点作为要求。如果你把某些文件视为第三方组件（其发布时间表不同于主产品），则可以采用这种方法。但是如果你没有这个要求，我建议仍然将所有文件版本保持同步。
我见过的一种行之有效的惯例是使用前3个数字表示产品版本（主/次等），而版本号的第4个部分表示源代码控制版本（这样你就知道二进制文件来自哪些源文件）。
希望这有所帮助，
约翰
我见过的一种行之有效的惯例是使用前3个数字表示产品版本（主/次等），而版本号的第4个部分表示源代码控制版本（这样你就知道二进制文件来自哪些源文件）。
希望这有所帮助，
约翰
- JohnD
1
在我看来，你应该只有一个共享于整个应用程序的AssemblyInfo文件。这样可以方便地维护它。当然，这意味着你所有的程序集都有一个单一版本，这对我来说是可以接受的标准。请参考this。
- Illuminati
2
3这取决于DLL是否是应用程序的一个组成部分，还是一个独立的项目。我目前正在开发一个应用程序，其中有一个库DLL可以在其他项目中使用。该库DLL具有自己的程序集信息，并且我们不保证它的版本号将与使用它的每个其他项目的版本号匹配。 - Robert Harvey
1@Robert Harvey，是的 - 当然可以。如果dll不是应用程序的组成部分，则无法使其使用共享的assemblyinfo。但在这个特定的问题中，似乎dll是应用程序的一部分。 - Illuminati
1
我认为你需要单独管理它们的版本。
因为两个应用程序（EXE）可以使用相同的DLL。 那么DLL的版本将是什么？
DLL的版本应该与运行它的EXE无关。
- Maxim
0
从另一个角度来看 - 为什么你需要版本号呢？例如，其中一个答案是要知道在某些客户端位置部署了什么。
因此，如果您有一个作为主exe和一些dlls部署的应用程序，并且这些dlls不是任何其他应用程序的一部分，即使您完全忘记了dll版本控制，您也可以感到安全。
否则，如果dll将成为多个项目的一部分，请将它们的版本号增加到任何您认为合理的方案，例如，在添加某些功能或更改某些较大内容时，将MINOR 1.X.0.0增加，如果您内部完全不同的类，则增加MAJOR。
至于因功能而增加MAJOR，当然又是个人口味问题，我建议像这样做：
- 如果添加了功能并达到了某个重要里程碑，请增加MINOR。 - 如果更改了用户界面范例，则增加MAJOR，这表明您进行了一些重大的重新设计或重写。
另外：版本语法解释？
因此，如果您有一个作为主exe和一些dlls部署的应用程序，并且这些dlls不是任何其他应用程序的一部分，即使您完全忘记了dll版本控制，您也可以感到安全。
否则，如果dll将成为多个项目的一部分，请将它们的版本号增加到任何您认为合理的方案，例如，在添加某些功能或更改某些较大内容时，将MINOR 1.X.0.0增加，如果您内部完全不同的类，则增加MAJOR。
至于因功能而增加MAJOR，当然又是个人口味问题，我建议像这样做：
- 如果添加了功能并达到了某个重要里程碑，请增加MINOR。 - 如果更改了用户界面范例，则增加MAJOR，这表明您进行了一些重大的重新设计或重写。
另外：版本语法解释？
- Daniel Mošmondor
0
你提到了一个非常广泛的话题，它可以变得像你允许的那样复杂。
最终，你选择的版本控制方法将取决于你需要实现什么以及你分配给维护它的时间有多少。这两者直接相关。
版本控制的两个主要目标是并行执行和跟踪。 并行执行（SxS）允许同一DLL的多个版本在同一应用程序中执行。如果不更改程序集版本号，则无法实现此目标。 跟踪只是能够确定正在客户机器上运行的确切代码快照。 通过更改程序集版本，两者都可以实现，但第一个目标只能通过更改程序集版本来实现。
许多人会建议你在所有DLL / EXE之间共享版本号-这是一种很好的方法，因为它是最简单的方法，但它也实现了最少的部署灵活性。
例如，如果您正在使用任何形式的合同抽象（通过接口而不是具体类型定义DLL之间的依赖关系），则可以将应用程序拆分为多个“版本隔离区”。 其中一个例子是客户端和服务器，其中依赖关系在第三个程序集中定义，即WCF合同。如果它们都单独进行版本控制，则可以发布新版本的服务器（只要符合相同的合同），而不影响客户端。反之亦然。正如您所看到的，随着需求增长，您将增加版本粒度，但这将产生额外开销。
您可以做的最好的事情就是正如您现在所做的一样，坐下来计划您的需求，然后绘制出您的版本边界（哪些组件可以通过合同分离）。
下一步取决于您的测试部门的规模，但我还建议您考虑使文件版本反映构建编号/日期（至少部分）。 每次发布新客户版时，您只会增加程序集版本，但对于每个DLL集合，应该有一个不同的文件版本，因为当您进行测试并发现问题时，这些DLL可唯一地识别，可以消除DLL来源的任何疑惑。
- Adam
0
简单的答案是在进行更改时增加版本号。不要保持EXE和DLL同步，因为它们没有理由这样做。DLL旨在是可移植的 - 任何EXE理论上都可以使用它。如果您已经有了DLL的版本号，则将其用作当前基线，并根据需要增加版本号。
- user195488
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接