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

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

从好处来看，它应该使管理服务器更容易一些。如果某个实例行为不正常，则可以在任务管理器中识别该实例。此外，不好的安装也不可能在没有注意到的情况下以混合组件版本结束

从反面来看，这将使发展更加困难。服务器不是一个独立的产品，而是我们应用程序基础架构的一部分。这意味着它将获得主应用程序的版本。因此，即使某个组件在不同版本之间根本没有更改，也必须使用不同的名称

总而言之，这不是一个关键问题。我们两方面都可以相处。话虽如此，我可能错过了一场支持其中一种策略的胜利者辩论。共同的选择是什么？你是做什么的

---

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

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

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

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

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

---

通过正确标记每个部件，并提供一个配置报告，说明哪些版本是当前版本，哪些版本必须一起使用，从而使这一点变得更容易。

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

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

---

一般来说，不要试图发明新的机制。使用现有的

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

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

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