可执行文件的名称中应该包含版本号吗？答案

【问题标题】：Should executables contain version numbers in their names?可执行文件的名称中应该包含版本号吗？
【发布时间】：2009-04-13 20:45:30
【问题描述】：

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

在专业方面，它应该使管理服务器更容易一些。如果某个实例行为不端，它将在任务管理器中被识别。此外，糟糕的安装不可能在不被注意的情况下以混合组件版本结束。

另一方面，它会使开发变得更加困难。服务器不是一个独立的产品，而是我们应用程序基础设施的一部分。这意味着它获取主应用程序的版本。鉴于此，即使版本之间根本没有更改某个组件，它也必须获得不同的名称。

总而言之，这不是关键问题。我们可能可以同时兼顾这两种方式。话虽如此，我可能错过了支持其中一种策略的赢家论点。常见的选择是什么？你是做什么的？

编辑：我熟悉 COM 和文件元数据版本控制，并且同意文件名版本控制是多余的。我试图找出更重要的东西——持续的冗余开销，或者维护方面的罕见收益。

【问题讨论】：

标签： windows naming-conventions versioning

【解决方案1】：

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

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

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

【讨论】：

【解决方案2】：

对于 COM API，您的库中确实拥有您需要的所有版本信息。我发现用版本号命名这些 DLL 充其量是多余的，最坏的情况是令人困惑（至少在版本号不同步的情况下）。每当我想要一个清晰的升级路径并防止任何更改时，我都倾向于将版本标识符附加到接口和 coclass 名称中。

对于普通的二进制 DLL API，附加版本号是一种想法，但我从未见过执行良好的方法（并且在那些旧的 16 位 VB 运行时 DLL 中执行得非常糟糕！）。他们是否有明确和分隔的 API，或者他们是否公开了几十个函数？如果接口很大，您将难以区分次要更改和重大更改。一旦您开始以这种方式标记版本，您就必须保持一致。每次版本更改都意味着必须重新编译静态链接客户端（因此重新标记自己的版本）。这里的潜在问题是您会收到很多“版本噪音”，从而隐藏了重要的更改。

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

【讨论】：

【解决方案3】：

我会说如果 DLL 在不同版本中提供不同的 API，版本号应该附加到文件名中。对于可执行文件没关系。如果可执行文件使用指定的接口进行交互，并且发生了变化，我还会在可执行文件的文件名中使用版本号。

【讨论】：

【解决方案4】：

“不利的一面是，这会使开发更加困难。”

不完全正确。它暴露了你已经遇到的一个问题——保持所有组件的所有版本对齐。

您必须确保应用程序基础架构作为一个整体具有所有组件的所有正确版本。

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

【讨论】：