我最近一直在版本化我的产品（exe）并每次在assemblyinfo.cs中增加内部版本号。
效果很好，我的产品目前是1.5.x.x版本，因此每次成功构建时都会增加4位数。
现在我的DLL也是我的应用程序的一部分。
有什么人会建议如何对这些进行版本化？我应该将这些版本与我的exe版本相同，即1.5.x.x，还是应该创建另一个不同的版本号？
这是我目前有点困惑的地方。
当我的产品功能增加时，我可以提高1.5到2.0，但这会留下我的dll？
非常感谢任何关于版本控制的建议
感谢
答案 0 :(得分：2)
你可能会得到多个意见，但我会说保持简单并让EXE和DLL版本保持同步。如果您真的打算独立发布DLL和EXE的版本，我可能会改变我的观点，但您没有提到它作为一项要求。如果您正在处理某些文件（如第三方组件（以与主产品不同的时间表发布），则可以使用此方法。但同样，如果你没有这个要求，我会说保持所有文件版本同步。
我见过的常规工作是使用前3个数字来表示产品版本（主要/次要等...），版本号的第4部分代表源代码控制版本（所以你确切知道哪个来源二进制来自的文件。）
希望有所帮助，
约翰
答案 1 :(得分：1)
在我看来，你应该只有一个在整个应用程序中共享的assemblyinfo文件。这样很容易维护它。当然，这意味着你所有的装配都有一个版本，这对我来说是可以接受的。参考this。
答案 2 :(得分：1)
在我看来，你必须分开管理他们的版本。
因为2个应用程序（EXE）可以使用相同的DLL。 DLL将是什么版本？
DLL的版本应该独立于运行它的EXE。
答案 3 :(得分：0)
从另一边看 - 为什么你需要版本号？例如，一个答案就是知道在某些客户位置部署了什么。
所以，如果你有部署为主exe和一些dll的应用程序，并且这个dll不是任何其他应用程序的一部分，即使你完全忘记了dll版本控制，你也会感到安全。
否则，如果dll将成为多个项目的一部分，请将它们的版本增加到对您来说合乎逻辑的ANY方案，例如，当您添加某些功能或更改相当大的内容时增加MINOR 1.X.0.0，增加MAJOR如果你里面有完全不同的课程，......
至于由于功能而增加MAJOR，当然这又是个人品味，我建议有类似的东西：
答案 4 :(得分：0)
你已经触及了一个非常大的主题，它实际上可以变得像你允许的那样复杂。
最终，您选择的版本控制方法取决于您需要实现的目标，以及您需要分配多少时间来维护它。这两者直接相关。
版本控制的两个主要目标是并行执行和跟踪。 并排（SxS）允许同一DLL的多个版本在同一个应用程序中执行。如果不更改程序集版本号，则无法进行此操作。 跟踪只是能够确定客户机器上运行的确切代码快照。 两者都可以通过更改程序集版本来实现，但第一个可以通过更改程序集版本来实现 。
许多人会建议你分享所有DLL / EXE的版本号 - 这是一个很好的方法，因为它是最简单的方法，它也实现了最小的部署灵活性。
例如，如果您使用任何形式的合同抽象（通过接口而不是具体类型定义DLL之间的依赖关系），您可以将应用程序拆分为多个“版本化孤岛”。 这方面的一个例子是客户端和服务器，如果在第3个程序集中定义了相互依赖性，则WCF会收缩。 如果它们都是单独版本化的，那么您可以发布新版本的服务器（只要它符合相同的合同），而不会影响客户端。反之亦然。
正如您所看到的，随着需求的增长，您将增加版本控制粒度，但会听到它。
您可以做的最好的事情就是您正在做的事情，坐下来计划您的要求，然后绘制您的版本边界（哪些组件可以通过合同分开）。
接下来的事情取决于测试部门的大小，但我还建议您查看文件版本（至少部分）反映内部版本号/日期。 每个客户版本只会增加一次程序集版本，但是对于从构建中发出的每个DLL集合，您应该有一个不同的文件版本。这是因为当您进行测试并找到问题时，将这些DLL唯一标识可以消除对DLL源自哪个版本的确切疑问。
答案 5 :(得分：0)
简单的答案是在进行更改时增加版本号。不要让EXE和DLL保持同步，因为它们没有理由。 DLL是可移植的 - 理论上任何EXE都可以使用它。如果您已拥有DLL的版本号，则将其用作当前基准，并在修改时根据需要增加版本号。