可执行文件是否应包含其名称中的版本号？

Question

我开发了某个服务器。到目前为止，无法同时安装两个版本。我们现在正在改变它，问题出现了：版本号是否应该附加到服务器组件？该服务器包含3个exes和5个dll（一些COM，一些原生VC ++）。是否有任何或所有名称都包含版本（ Serv71.exe ， module71.dll ）？

在专业方面，它应该使管理服务器更容易一些。如果某个实例行为异常，则可以在任务管理器中识别。此外，如果没有注意到混合组件版本，那么糟糕的安装将无法结束。

在缺点方面，它会使开发变得更加困难。服务器不是独立产品，而是我们应用程序基础架构的一部分。这意味着它获得了主应用程序的版本。如果给定，某个组件必须获得不同的名称，即使版本之间没有任何变化。

总而言之，这不是一个至关重要的问题。我们可以两种方式相处。话虽如此，我可能错过了赢家的观点，赞成其中一个策略。常见的选择是什么？你做什么的？

编辑：我熟悉COM和文件元数据版本控制，并同意文件名版本控制是多余的。我试图弄清楚什么是更重要的 - 不断的冗余开销，或维护中罕见的增益。

Answer 1

通常，版本信息是DLL的元数据（文件扩展信息）的一部分，而不是文件名的一部分。

维护过程更容易。升级/替换现有二进制文件时，安装程​​序知道如何使用该信息。如果您需要发布新版本的DLL，则无需重新编译/重新链接您的exe。

作为一般准则 - 不要试图发明新的机制。使用现有的。

Answer 2

对于COM API，您确实拥有库中所需的所有版本控制信息。我发现命名这些DLL的版本号最多是冗余的，在最坏的情况下会令人困惑（至少如果版本号不同步）。我希望每当我想要一个明确的升级路径并反对任何更改时，都会在接口和coclass名称上附加一个版本标识符。

对于普通的二进制DLL API，附加版本号是一个想法，但不是我曾经看过很好的执行（并且在那些旧的16位VB运行时DLL中执行得非常糟糕！）。他们是否有明确的分隔API，或者它们是否暴露了许多功能？如果接口很大，你将遇到一个问题，即从一个重大变化中解决一个未成年人。一旦你开始以这种方式标记版本，你就必须保持一致。每个版本的更改都意味着必须重新编译静态链接客户端（因此版本会自行重新标记）。这里潜在的问题是你得到了很多'版本噪音'，隐藏了重要的变化。

Windows二进制文件包含版本元数据（VERSIONINFO结构）。正如LeJeune所说，这是一条众所周知的路线，虽然当你把错误的东西连在一起时，它不会自动导致错误。但是，您可以相对轻松地利用它来支持您需要的任何配置管理架构。

Answer 3

我想说如果DLL在不同版本中提供不同的API，那么版本号应该附加到文件名。对于可执行文件，它并不重要。如果可执行文件使用指定的接口进行交互，并且更改，我还将使用可执行文件的文件名中的版本号。

Answer 4

“在缺点方面，它会使开发变得更加困难。”

不完全正确。它暴露了您已经存在的问题 - 保持所有组件的所有版本一致。

您必须确保整个应用程序基础架构具有所有组件的所有适当版本。

通过正确标记每个部分，并提供配置报告，说明哪些版本是最新的以及哪些版本必须一起使用，使更容易。