.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.1Git提交哈希：
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文件中添加一个
<InformationalVersion>属性。
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net8.0</TargetFramework>
<ImplicitUsings>enable</ImplicitUsings>
<Nullable>enable</Nullable>
<!-- 直接设置值 -->
<InformationalVersion>2.1.0-preview.5</InformationalVersion>
<!-- 或者，结合MSBuild属性动态生成，这在CI/CD中非常有用 -->
<!-- <InformationalVersion>$(VersionPrefix)-$(BuildNumber)</InformationalVersion> -->
</PropertyGroup>
<!-- ... 其他配置 -->
</Project>当项目构建时，MSBuild会自动从这个
<InformationalVersion>属性生成
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<AssemblyInformationalVersionAttribute>()?
.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(); // 替换成你实际要获取的Assembly
string targetInformationalVersion = targetAssembly
.GetCustomAttribute<AssemblyInformationalVersionAttribute>()?
.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中，我们可以这样设置：
<PropertyGroup> <!-- 默认值，用于本地开发 --> <InformationalVersion Condition="'$(BUILD_BUILDNUMBER)' == ''">1.0.0-LocalDev</InformationalVersion> <!-- CI/CD环境会覆盖此值 --> <InformationalVersion Condition="'$(BUILD_BUILDNUMBER)' != ''">1.0.0-CI.$(BUILD_BUILDNUMBER)-$(GitCommitShortHash)</InformationalVersion> </PropertyGroup>
在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流程中扮演着一个信息桥梁的角色，它将复杂的构建和代码历史信息，以一种易于理解和追踪的方式，嵌入到最终的二进制文件中，极大地提升了开发、测试和运维的效率。
