可执行文件的名称中是否应该包含版本号？
我开发了某个服务器。 目前还无法同时安装两个版本。 我们现在正在改变这一点，问题出现了：版本号是否应该附加到服务器组件？ 服务器包含 3 个 exe 和 5 个 dll（一些 COM，一些本机 VC++）。 是否有任何一个或全部的名称包含版本（Serv71.exe、module71.dll）？
从优点来看，它应该使服务器的管理变得更容易。 如果某个实例行为不当，它可以在任务管理器中识别出来。 此外，错误的安装不可能以混合组件版本而告终而不被注意到。
不利的一面是，这会让开发变得更加困难。 服务器不是一个独立的产品，而是我们应用程序基础设施的一部分。 这意味着它获取主应用程序的版本。 鉴于此，某个组件必须获得不同的名称，即使它在版本之间根本没有改变。
总而言之，这并不是一个关键问题。 我们也许可以两种方式相处。 话虽如此，我可能错过了支持其中一种策略的胜利者论点。 常见的选择是什么？ 你做什么工作？
编辑：我熟悉 COM 和文件元数据版本控制，并且同意文件名版本控制是多余的。 我试图弄清楚什么更重要——持续的冗余开销，还是维护方面的罕见收益。
I develop a certain server. Till now, two versions could not be installed at the same time. We're now changing that, and the question came up: should the version number be appended to the server components or not? The server contains 3 exes and 5 dlls (some COM, some native VC++). Should any or all have their name contain the version (Serv71.exe, module71.dll) or not?
On the pros side, it should make managing the server a bit easier. If a certain instance misbehaves it would be identifiable in the task manager. Also, there's no chance a bad installation will end with having mixed components versions without it being noticed.
On the cons side, it would make development a bit harder. The server is not a standalone product, but rather a part of our applications infrastructure. This means it gets the main app's version. That given, a certain component will have to get a different name even if it hasn't changed at all between versions.
All in all, this is not a crucial issue. We can probably get along with both ways. Having that said, I might have missed a winner argument in favor of one of the strategies. What is the common choice? what do you do?
Edit: I'm familiar with COM and file metadata versioning, and agree filename versioning is redundant. I'm trying to figure out what's more significant - the constant redundancy overhead, or the rare gain in maintenance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
通常版本信息是 DLL 元数据（文件扩展信息）的一部分，而不是文件名的一部分。
维护过程更加容易。 当您升级/替换现有二进制文件时，安装程序知道如何使用该信息。 如果您需要发布新版本的 DLL，则无需重新编译/重新链接您的 exe。
作为一般准则——不要尝试发明新机制。 使用现有的。
Usually version information is part of the meta data (file extended information) of the DLL and not part of the file name.
The process of maintenance is easier. Setup programs know how to work with that info when you upgrade/replace an exisiting binary file. If you need to issue a new version of the DLL, you dont need to recompile/relink your exe.
As a general guideline -- don't try to invent new mechanisms. Use existing ones.
对于 COM API，您的库中确实拥有所需的所有版本控制信息。 我发现用版本号命名这些 DLL 往好了说是多余的，往坏了说是令人困惑的（至少在版本号不同步的情况下）。 每当我需要清晰的升级路径并预期任何更改时，我都喜欢将版本标识符附加到接口和组件类名称中。
对于普通的二进制 DLL API，附加版本号是一个想法，但我从未见过执行得好的想法（在那些旧的 16 位 VB 运行时 DLL 中执行得非常糟糕！）。 它们是否具有清晰且分隔的 API，或者是否公开了数十个函数？ 如果接口很大，您将很难区分次要更改和重大更改。 一旦你开始以这种方式标记版本，你就必须保持一致。 每个版本更改都意味着必须重新编译静态链接的客户端（因此版本会重新标记自己）。 这里潜在的问题是你会得到很多“版本噪音”，隐藏了重要的更改。
Windows 二进制文件包含版本元数据（VERSIONINFO 结构）。 正如 LeJeune 所说，这是一条众所周知的路线，尽管当您将错误的内容链接在一起时不会自动导致错误。 然而，您可以相对轻松地利用它来支持您需要的任何配置管理模式。
For COM API's, you really have all the versioning information you need in your libraries. I'd find naming those DLL's with version numbers redundant at best, confusing at worst (at least if version numbers get out of synch). I favour appending a version identifier to interface and coclass names whenever I want a clear upgrade path and anticpate any changes.
For plain binary DLL API's, appending version numbers is an idea, but not one I've ever seeen well executed (and quite terribly executed in those old 16 bit VB runtime DLL's!). Do they have clear and delimited API's, or do they expose dozens of functions? You're going to have problems distingushing a minor from a breaking change if the interfaces are large. Once you start labelling versions this way, you're going to have to be consistent. Every version change will mean that statically linking clients have to be recompiled (and hence version relabelled themselves). The potential problem here is that you get a lot of 'version noise', hiding the important changes.
Windows binaries contain version metadata (the VERSIONINFO structure). As LeJeune says, that's a well-known route, albeit one that deosn't automatically cause errors when you link the wrong stuff together. However, it's one you can relatively easily leverage to support whatever configuration management schema you need.
我想说的是，如果 DLL 在不同版本中提供不同的 API，则应将版本号附加到文件名中。 对于可执行文件来说这并不重要。 如果可执行文件使用指定的接口进行交互，并且情况发生变化，我还会在可执行文件的文件名中使用版本号。
I'd say if the DLLs provide different APIs in different versions, the version number should be appended to the filename. For executables it doesn't matter. If the executable interact using a specified interface, and that changes, I'd also use the version number in the filenames of the executables.
“从缺点来看，这会让开发变得更加困难。”
不完全正确。 它暴露了您已经遇到的一个问题——保持所有组件的所有版本保持一致。
您必须确保应用程序基础架构作为一个整体拥有所有组件的所有正确版本。
通过正确标记每个部分并提供配置报告来说明哪些版本是最新的以及哪些版本必须一起使用，可以使此过程变得更容易。
"On the cons side, it would make development a bit harder."
Not completely true. It exposes an problem you already have -- keeping all the releases of all the components aligned.
You have to make sure that the applications infrastructure as a whole has all the proper releases of all of the components.
Make this easier by properly labeling each piece, and providing a configuration report that says which versions are current and which versions must be used together.