AssemblyInformationalVersionAttribute用于为.NET程序集添加灵活的、信息性的版本标签，不影响运行时绑定，可包含预发布标识、Git哈希、构建号等丰富元数据，常用于CI/CD中实现版本追溯与自动化管理。
.NET中的
AssemblyInformationalVersionAttribute
类，简单来说，它就是用来给你的程序集打上一个“产品版本”的标签，这个版本号通常是给用户或外部系统看的，比严格的
AssemblyVersion
或
AssemblyFileVersion
要灵活得多，可以包含各种自定义信息，比如预发布标识、构建号甚至Git提交哈希。它不会影响CLR加载程序集的行为，纯粹是信息展示用途。
解决方案
AssemblyInformationalVersionAttribute
（位于
System.Reflection
命名空间）是一个非常实用的特性，它允许开发者为程序集指定一个非规范化的版本字符串。与
AssemblyVersion
和
AssemblyFileVersion
不同，
AssemblyInformationalVersion
的值可以包含任何文本，例如”1.0.0-beta.1″、”2023.Q4.Release”、”v5.2.0-preview.githash”等。这种灵活性是其核心价值所在。
在软件开发中，尤其是在持续集成/持续部署（CI/CD）的流程里，我们经常需要一个能反映更多上下文信息的版本号。比如，我想知道用户反馈的某个Bug是哪个特定的内部构建版本产生的，或者哪个预发布版本正在测试中。如果只依赖
AssemblyVersion
（通常是严格的Major.Minor.Build.Revision格式，且会影响程序集绑定）或
AssemblyFileVersion
（文件系统层面的版本），往往无法承载这些丰富的元数据。而
AssemblyInformationalVersionAttribute
就完美解决了这个问题，它提供了一个“自由发挥”的文本字段，既可以方便地嵌入到应用程序的“关于”界面，也可以用于日志记录或错误报告，帮助我们快速定位问题来源。
为什么我们需要AssemblyInformationalVersionAttribute，它和AssemblyVersion、AssemblyFileVersion有什么区别？
这个问题常常困扰着初学者，甚至是一些经验丰富的开发者也容易混淆。我认为，理解它们各自的职责是关键。
AssemblyVersion
：这是最严格的版本号，它直接影响.NET运行时（CLR）如何绑定和加载程序集。如果你引用了一个库的
AssemblyVersion
是1.0.0.0，而部署时这个库的
AssemblyVersion
变成了1.0.0.1，那么你的应用程序很可能会因为版本不匹配而崩溃（除非有绑定重定向）。它通常遵循“主版本.次版本.构建号.修订号”的严格数字格式。对开发者来说，频繁更改
AssemblyVersion
是一件需要谨慎对待的事情，因为它会带来兼容性问题。
AssemblyFileVersion
：这个版本号更多是操作系统层面的概念。你在Windows文件资源管理器中查看DLL或EXE文件的属性时，看到的“文件版本”就是它。它也通常是数字格式，可以和
AssemblyVersion
不同，比如，我可能发布了一个
AssemblyVersion
是1.0.0.0的库，但它的
AssemblyFileVersion
是1.0.0.1234，表示这是第1234个内部构建版本。它的主要作用是帮助文件系统和部署工具识别文件的特定版本。
AssemblyInformationalVersionAttribute
：这就是我们今天的主角。它完全是“信息性”的。它不影响CLR的绑定，也不直接影响文件系统。它只是一个字符串，你可以把它想象成产品的“营销版本”或“显示版本”。我个人非常喜欢用它来承载一些非标准但非常有用的信息，比如：
预发布标识：
1.0.0-beta.2
、
2.0.0-rc.1
Git提交哈希：
1.0.0+abcdef123
，这在追踪生产环境中的代码版本时简直是救命稻草。CI/CD构建号：
1.0.0-build.4567
，直接对应到我的构建系统中的某个特定构建。自定义文本：
MyProduct v3.1 (Internal Test Build)
它存在的意义，就在于提供一个既能满足人类阅读需求，又能包含丰富元数据的版本标识，同时又不会干扰到程序集的核心运行时行为。
如何在项目中设置和获取AssemblyInformationalVersionAttribute的值？
设置和获取
AssemblyInformationalVersionAttribute
的值，在.NET项目中其实很直接，但根据项目类型（旧的.NET Framework项目还是新的SDK风格项目）会有一些细微差别。
设置值：
对于旧的.NET Framework项目或非SDK风格项目（通常在
Properties/AssemblyInfo.cs
文件）：你会在
AssemblyInfo.cs
文件中找到一系列
[assembly: ...]
的特性。只需添加或修改
AssemblyInformationalVersion
这一行即可。
using System.Reflection;// ...[assembly: AssemblyInformationalVersion("1.0.0-beta.3+commit.1a2b3c4d")]
这种方式是直接硬编码，如果要动态生成，可能需要构建脚本去修改这个文件。
对于现代SDK风格的.NET项目（如.NET Core/.NET 5+项目，在
.csproj
文件）：这是我目前最推荐的方式，因为它更简洁，并且能更好地与MSBuild和CI/CD流程集成。你可以在项目的
.csproj
文件中添加一个
属性。
net8.0 enable enable 2.1.0-preview.5 <!-- $(VersionPrefix)-$(BuildNumber) -->
当项目构建时，MSBuild会自动从这个
属性生成
AssemblyInformationalVersionAttribute
。这种方式的强大之处在于，你可以利用MSBuild的条件判断和属性覆盖机制，在构建时动态注入版本信息。
获取值：
在运行时获取
AssemblyInformationalVersionAttribute
的值也很简单，通常通过反射来完成：
获取当前执行程序集的信息：
using System;using System.Reflection;public class Program{ public static void Main(string[] args) { Assembly currentAssembly = Assembly.GetExecutingAssembly(); string informationalVersion = currentAssembly .GetCustomAttribute()? .InformationalVersion; Console.WriteLine($"当前应用程序版本: {informationalVersion ?? "未设置"}n"); // 对于桌面应用（WPF/WinForms）或控制台应用，ProductVersion属性通常会映射到InformationalVersion // 如果InformationalVersion未设置，它会回退到AssemblyVersion Console.WriteLine($"Application.ProductVersion: {System.Windows.Forms.Application.ProductVersion}"); // 仅WinForms示例 // 或 Environment.Version 对于运行时版本，Application.ProductVersion 对于应用程序版本 }}
获取特定已加载程序集的信息：如果你想获取一个已经加载到内存中的其他DLL或EXE的
AssemblyInformationalVersion
，可以先获取到它的
Assembly
对象：
// 假设你已经加载了名为 "YourLibrary.dll" 的程序集// Assembly targetAssembly = Assembly.LoadFrom("path/to/YourLibrary.dll"); // 或 Assembly.Load("YourLibraryName");// 假设我们这里就用当前程序集作为例子Assembly targetAssembly = Assembly.GetExecutingAssembly(); // 替换成你实际要获取的Assemblystring targetInformationalVersion = targetAssembly .GetCustomAttribute()? .InformationalVersion;Console.WriteLine($"目标程序集版本: {targetInformationalVersion ?? "未设置"}");
通过这种方式，你的应用程序就可以在“关于”对话框、诊断日志或API响应中显示一个友好的、包含丰富信息的版本字符串，这对于用户支持和内部调试都非常有帮助。
在CI/CD流程中，如何利用AssemblyInformationalVersionAttribute实现自动化版本管理？
这正是
AssemblyInformationalVersionAttribute
真正发挥其魔力的地方，尤其是在现代DevOps实践中。手动管理版本号不仅效率低下，而且极易出错。自动化是必然趋势。
我的做法通常是这样的：
动态注入构建信息：在CI/CD管道中，我可以利用环境变量、构建参数或脚本来动态生成
InformationalVersion
。例如，在Azure DevOps或GitHub Actions中，我可以访问到当前的构建ID、Git提交哈希、分支名称等信息。
结合Git提交哈希： 这是我最喜欢的一种方式。在
InformationalVersion
中嵌入Git的短提交哈希，比如
1.0.0-beta.1+abcdef123
。这样，当一个用户报告一个Bug，我拿到这个版本号，就能立即回溯到代码仓库中精确的那个提交点。这对于快速调试和复现问题至关重要。结合CI/CD构建号： 许多CI系统都有一个递增的构建号。将其包含在版本字符串中，如
1.0.0-build.4567
。这有助于追踪CI历史。结合分支名和日期/时间： 对于非主干分支的构建，可以加上分支名，例如
1.0.0-feature-xyz.20231027
，这样可以清晰区分不同开发线的构建。
通过MSBuild属性传递：如前所述，在SDK风格的
.csproj
中，我们可以这样设置：
1.0.0-LocalDev 1.0.0-CI.$(BUILD_BUILDNUMBER)-$(GitCommitShortHash)
在CI/CD管道中执行
dotnet build
时，我可以通过
/p
参数传递这些属性：
dotnet build MyProject.csproj /p:BUILD_BUILDNUMBER=$(Build.BuildId) /p:GitCommitShortHash=$(Build.SourceVersion.Substring(0, 7))
(Azure DevOps示例)
使用专业的版本管理工具：有一些工具，比如
Nerdbank.GitVersioning
，能够根据Git仓库的历史和标签，自动生成符合SemVer规范的、包含Git元数据的版本号，并自动设置
AssemblyInformationalVersion
以及其他版本属性。这极大地简化了版本管理工作。它能自动生成类似
1.2.3-alpha.4+gfedcba
这样的版本字符串，非常强大。
自动化版本管理的实际价值：
极强的可追溯性： 任何一个部署的二进制文件，都能清晰地告诉我它来自哪个代码提交，哪个构建任务。简化调试： 报告的Bug版本号直接指向代码，省去了“这是哪个版本？”的反复确认。清晰的发布管理： 能够明确区分正式发布版、内部测试版、预发布版等，避免混淆。减少人为错误： 自动化消除了手动修改版本号可能带来的疏漏和错误。
总之，
AssemblyInformationalVersionAttribute
在CI/CD流程中扮演着一个信息桥梁的角色，它将复杂的构建和代码历史信息，以一种易于理解和追踪的方式，嵌入到最终的二进制文件中，极大地提升了开发、测试和运维的效率。
以上就是.NET的AssemblyInformationalVersionAttribute类的作用是什么？的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1439205.html
微信扫一扫 
支付宝扫一扫 
