.net：DLL 与 EXE 的版本号？
我最近一直在对我的产品 (exe) 进行版本控制，并每次都在 assemblyinfo.cs 中增加内部版本号。
效果很好，我的产品目前版本为 1.5.xx，因此每次成功构建时都会增加 4 位数字。
现在我有了 DLL，它们也是我的应用程序的一部分。
我如何对这些版本进行版本控制？我应该将它们的版本设置为与我的 exe 相同，即 1.5.xx 还是应该创建另一个不同的版本号？
这是我目前有点困惑的地方。
当我的产品功能增加时，我可以将 1.5 提高到 2.0，但这会将我的 DLL 留在哪里？
I have been recently versioning my product (exe) and increasing the build number each time in assemblyinfo.cs.
Works great, my product is currently on version 1.5.x.x so in increase the 4 digit each time I have a successful build.
Now I have my DLLs which are also part of my application.
How could I version these? Should I version these the same as my exe i.e, 1.5.x.x or should i create another different version number?
This is where I am currently a little confused.
When my product increases in functionality I can raise 1.5 to 2.0 but where does this leave my DLLs?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
您可能会得到多种意见，但我想说的是保持简单并让 EXE 和 DLL 版本保持同步。如果您确实打算独立发布 DLL 和 EXE 的版本，但您没有将其作为要求提及，我可能会改变我的观点。如果您将某些文件视为第 3 方组件（其发布时间与主产品不同），则可以采用此方法。但同样，如果您没有此要求，我想说只需保持所有文件版本同步即可。
我见过的行之有效的约定是使用前 3 个数字来表示产品版本（主要/次要等），版本号的第四部分表示源代码控制版本（这样您就可以准确地知道二进制文件是哪些源文件）来自）。
希望有帮助，
约翰
You'll probably get multiple opinions, but I would say to keep it simple and have the EXEs and the DLLs version stay in sync. I might change my opinion if you really intend to release versions of the DLLs and EXEs independently, but you don't make any mention of that as a requirement. You would take this approach if you are treating some of your files like 3rd-party components (which are released on a different schedule from the main product). But again, if you don't have this requirement, I would say just keep all the file versions in sync.
The convention I have seen work well is to use the first 3 numbers to represent the product version (major/minor etc..) and the 4th part of the version number represents the source control version (so you know exactly which source files the binary came from).
Hope that helps,
John
在我看来，你必须单独管理它们的版本。
因为2个应用程序（EXE）可以使用同一个DLL。
DLL 是什么版本？
DLL 的版本应该独立于运行它的 EXE。
In my opinion you have to manage their versions separate.
Because 2 applications(EXE) can use the same DLL.
What version the DLL will be ?
The DLL's version should be independent of the EXE that runs it.
在我看来，您应该只有一个在应用程序之间共享的 assemblyinfo 文件。这样就很容易维护它。当然，这意味着您的所有程序集都有一个版本，这对我来说是可以接受的规范。请参阅此< /a>.
In my opinion you should have only one assemblyinfo file that is shared across the application. That way it is easy to maintain it. And of course it implies you have a single version for all your assemblies which is the acceptable norm to me. refer this.
从另一方面来看——为什么需要版本号？例如，对此问题的一个答案可能是了解在某些客户端位置部署了什么。
因此，如果您有部署为主 exe 和一些 dll 的应用程序，并且该 dll 不属于任何其他应用程序，那么即使您完全忘记 dll 版本控制，您也可以感到安全。
否则，如果 dll 将成为多个项目的一部分，请将其版本增加到对您来说似乎合乎逻辑的任何方案，例如，当您添加某些功能或更改相当大的内容时增加 MINOR 1.X.0.0，如果有，则增加 MAJOR里面完全不同的类，...
至于由于功能而增加 MAJOR，这当然又是个人品味，我建议：
另：版本语法说明？
Look it from the other side - why do you NEED version numbers? For example one answer to that can be to know what is deployed at some clients location.
So, if you have application that is deployed as main exe and some dlls, and this dlls AREN'T part of any other app, you can feel safe even if you completely forget about dll versioning.
Otherwise, if the dlls will be part of multiple projects, increase their version to ANY scheme that seems logical to you, for example, increase MINOR 1.X.0.0 when you add some functionality or change something rather large, increase MAJOR if you have completely different classes inside, ...
As for increasing MAJOR because of the functionality, that is of course again personal taste, I would advise there something like:
Also: Version Syntax Explanation?
您触及了一个非常大的主题，该主题实际上可能会变得非常复杂，只要您愿意。
最终，您选择的版本控制方法将取决于您需要实现的目标，以及您需要分配多少时间来维护它。两者是直接相关的。
版本控制的两个主要目标是并行执行和跟踪。
并行 (SxS) 允许同一 DLL 的多个版本在同一应用程序中执行。如果不更改程序集版本号，这是不可能的。
跟踪只是能够确定在客户计算机上运行的确切代码快照。
两者都可以通过更改程序集版本来实现，但第一个只能通过更改程序集版本来实现。
许多人会建议您在所有 DLL/EXE 之间共享版本号 - 这是一个很好的方法，因为它是最简单的方法，但它也实现了最低的部署灵活性。
例如，如果您使用任何形式的契约抽象（通过接口而不是具体类型定义 DLL 之间的依赖关系），您可以将应用程序拆分为多个“版本控制孤岛”。
一个例子是客户端和服务器，如果在第三个程序集中定义相互依赖性，则您的 WCF 合同。
如果它们都是单独版本化的，那么您可以发布新版本的服务器（只要它符合相同的合同），而不会影响客户端。反之亦然。
正如您所看到的，随着需求的增长，您将增加版本控制粒度，但这会导致无意中听到。
你能做的最好的事情就是你正在做的事情，坐下来规划你的需求，然后规划出你的版本控制边界（哪些组件可以通过合同分开）。
接下来的事情取决于您的测试部门的规模，但我还建议您考虑让文件版本反映（至少部分）内部版本号/日期。
对于每个客户版本，您只需增加一次程序集版本，但对于构建过程中产生的每个 DLL 集合，您应该拥有不同的文件版本。这是因为当您进行测试并发现问题时，让这些 DLL 具有唯一可识别性将消除对 DLL 究竟源自哪个版本的任何疑问。
You have touched on a very large topic, which really can get as complicated as you will allow it.
Ultimately, the versioning approach you choose will be dependent on what you need to achieve, and how much time you have to allocate to maintaining it. The two are directly related.
The two primary goals of versioning, is side-by-side execution, and tracking.
Side-by-side (SxS) is allowing multiple versions of the same DLL to execute within the same application. Without the changing of an assembly-version-number, this is not possible.
Tracking is simply being able to determine the exact code snapshot that is running on a customers machine.
Both can be achieved by changing the assembly-version, but the first can be achieved only by changing the assembly-version.
Many will reccommend you share the version numbers across all DLLs/EXEs - this is a good way to do it, as it is the most simplistic approach, it also achieves the least deployment flexibility.
For example, if you are using any form of contract abstraction (defining dependencies between DLLs via interfaces rather than concrete types), you may split your application into multiple 'versioning silos'.
An example of this would be client, and server, where the interdepency if defined in a 3rd assembly, your WCF contracts.
If they are all versioned separately, then you can release a new version of server (so long as it conforms to the same contract), without affecting the client. And vice-versa.
As you can see, you will increase your versioning granularity as your demands grow, but it will incur overheard.
The best thing you can do is exactly what you are doing, sit down and plan your requirements, then map out your versioning boundaries (which components can be separated by contracts).
This next thing depends on the size of your testing department, but I would also recommend that you look at having the file-version reflect (at least in part) the build number/date.
You will only increment the assembly-version once per customer release, but you should have a different file version for each collection of DLLs that comes out of the build. This is because when you're testing, and you locate an issue, having these DLLs uniquely identifiable will remove any doubt as to exactly which build the DLL originated.
简单的答案是在进行更改时增加版本号。不要使 EXE 和 DLL 保持同步，因为它们没有理由保持同步。 DLL 旨在可移植 - 理论上任何 EXE 都可以使用它。如果您已有 DLL 的版本号，请使用它作为当前基准，并在修改它时根据需要增加版本号。
Simple answer is to increase the version numbers as you make changes. Don't keep the EXE and DLL in sync because there is no reason for them to be. The DLL is intended to be portable - any EXE could theoretically use it. If you already have a version number for the DLL, then use that as your current baseline and as you modify it, increase the version number as needed.