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