如果代码发生更改，如何自动增加程序集的版本？
如果在构建解决方案后程序集发生了更改，有没有一种方法可以自动增加程序集的版本号？
我尝试过构建后事件，但随后您会在每次构建时增加版本，而不仅仅是构建过程因更改而编译了任何内容。
提前致谢。
编辑：我想要做的是自动增加程序集的版本号，每次我执行“构建解决方案”时都会更改代码，以避免手动更改它。这样我就可以确保具有相同版本的 2 个程序集始终具有相同的代码。
there is a way of incrementing the version number of an assembly automatically if the assembly has changed after doing a build of the solution?
I've tried with post-build events but then you increment the version on each build, not only if the build process has compiled anything due to changes.
Thanks in advance.
EDIT: What I want to do is to automatically increment the version number of the assemblies where I change code each time that I do a "Build Solution" to avoid changing it by hand. This way I can be sure that 2 assemblies with the same version ALWAYS have the same code.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
是的，您可以通过在 [AssemblyVersion] 属性中使用 * 来自动增加版本。不幸的是，这很少是正确的。 Microsoft 应该做的是赋予 [AssemblyFileVersion] 该功能。他们没有。
[AssemblyVersion] 是一个非常重要的属性，CLR 使用它来验证加载的程序集是否与编译代码时使用的程序集兼容。 “兼容”意味着：程序集将与客户端代码完美配合，不会对程序集源代码进行任何更改，否则如果客户端未重新编译，则可能导致程序集无法正常工作。使用该定义，错误修复更新非常兼容。重新组织程序集中类的内部实现的更新也可能非常兼容。对公开可见的类或成员的更改可能不兼容。尽管 JIT 编译器非常擅长检测更改何时严重不兼容（例如删除以前的公共成员）。
在属性中使用 * 本质上意味着：它始终不兼容。即使您根本没有更改任何代码，再次构建程序集后也会不兼容。这在大多数情况下都是毫无用处的，除非您总是将程序集与其客户端代码一起构建。并将它们重新部署在一起。这是可行的，但是版本号的概念就变得毫无用处了。
长话短说：在我看来，你应该自己管理程序集版本。当您在程序集的公共接口中进行重大更改时，请更改它。这当然是微软所采取的方法。 .NET 2.0 程序集在 .NET 3.5 SP1 框架中仍标记为版本 2.0.0.0。尽管它们实际上不再兼容，但后来添加了 WaitHandle.WaitOne(int) 。在过去的五年里，他们在保持兼容性方面做得非常出色，这绝非易事。
请注意，这些都不适用于 [AssemblyFileVersion]，为每个构建自动递增它是非常合适的。
Yes, you can get automatic version incrementing by using * in the [AssemblyVersion] attribute. Unfortunately, that is rarely correct. What Microsoft should have done is give the [AssemblyFileVersion] that capability. They didn't.
[AssemblyVersion] is a very important attribute, used by the CLR to verify that the assembly that got loaded is compatible with the assembly that was used when the code was compiled. "Compatible" means: the assembly is going to work cleanly with the client code, no changes were made to the assembly source code that could make it fail to work correctly if the client wasn't recompiled. Using that definition, a bug fix update is very compatible. An update that reorganized the internal implementation of the classes in the assembly could be very compatible as well. Changes to publicly visible classes or members is likely to not be compatible. Although the JIT compiler is very good at detecting when the changes were grossly incompatible (like removing a previously public member).
Using * in the attribute essentially means: it is always incompatible. Even if you didn't change any code at all, the assembly will be incompatible after it is built again. That's pretty useless in most any scenario, except if you always build the assembly together with its client code. And redeploy them together. That works, but then the notion of having a version number at all becomes fairly useless.
Long story short: IMO you should manage the assembly version yourself. Change it when you make a breaking change in the public interface of the assembly. That's certainly the approach that Microsoft takes. .NET 2.0 assemblies are still marked as version 2.0.0.0 in the .NET 3.5 SP1 framework. Even though they are not actually compatible anymore, WaitHandle.WaitOne(int) got added later. They did otherwise a stellar job of maintaining compatibility for the past 5 years, it couldn't have been easy.
Note that none of this applies to [AssemblyFileVersion], auto incrementing it for every build is very appropriate.
我建议使用这个： https://github.com/dotnet/Nerdbank.GitVersioning
版本该工具生成的编号是基于git信息的。这样，当您更改代码时，版本号也会更改。并且有很多自定义设置。
I recommend using this: https://github.com/dotnet/Nerdbank.GitVersioning
The version number generated by this tool is based on the git information. So that when you change your code, the version number will change. And there are many customize settings.
如果我对这个过程的理解是正确的，那么当您构建解决方案时，只有已更改的程序集（或链接的程序集已更改的程序集）才会被重建。
如果程序集根本没有更改，则不会重新编译（除非您使用“rebuild all”命令）
所以在我的项目中，每个项目的 AssemblyInfo.cs 内，我有这一行：
这会产生不同的版本我的集会号码。
If my understanding of the process is correct, when you do a build of your solution, only the assemblies that have changed (or those where linked assemblies have changed) are rebuilt.
If an assembly didn't change at all, it won't be recompiled (unless you use "rebuild all" command)
So in my projects, inside AssemblyInfo.cs of each project, I have this line:
And this prodcuces me different version numbers for my assemblies.
如果您想要每次编译完成时更新的自动递增数字，您可以使用 VersionUpdater预构建事件。与 MSDN 上描述的默认编号机制相比，这具有更多控制的优点。
If you want an auto incrementing number that updates each time a compilation is done, you can use VersionUpdater from a pre-build event. This has the advantage of more control than the default numbering mechanism described on MSDN.