同一DLL为何存在多版本信息？各版本字段作用及统一疑问

我首次碰到「无法加载文件或程序集版本问题」，已经了解assemblyBinding的作用，相关配置如下：

<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Runtime" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-7.0.0.0" newVersion="4.1.2.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

但仍不清楚其他版本信息的用途，以下是相关问题的解答：

1. 红框标注的Runtime版本作用 #

这里的Runtime版本指的是程序集版本（Assembly Version），它是.NET运行时识别、绑定程序集的核心标识。和assemblyIdentity中的名称、公钥令牌、区域信息一起，唯一确定一个强命名程序集。运行时加载程序集时会严格匹配这个版本号（除非配置了绑定重定向），版本不匹配就会触发加载失败异常。这个版本通常只在程序集有重大API变更时才修改，目的是避免旧代码调用不兼容的新API。

2. 黄框的文件版本有何作用 #

文件版本（File Version）属于文件元数据，不参与.NET运行时的程序集绑定逻辑，主要给开发者、运维人员做版本标识用。你可以用它记录更细粒度的迭代信息，比如日常构建号、补丁版本，方便排查问题时确认部署的具体文件版本。比如同一个程序集版本下，可能有多个不同的文件版本，用来区分不同的补丁包。

3. 绿框版本还有其他用途吗 #

如果绿框版本指的是产品版本（Product Version），它同样是元数据，不影响运行时绑定。除了作为版本标识，它还能用于：

• 应用「关于」页面展示产品整体版本
• 安装程序、自动更新的版本检测依据
• 运维时快速识别产品的版本阶段（比如正式版、测试版）

4. 为何不能为每个DLL设置唯一版本 #

不是不能，而是这么做会带来大量不必要的麻烦：

• 绑定复杂度飙升：每个DLL用唯一版本，项目依赖关系会变得异常复杂，需要配置大量绑定重定向，稍有疏忽就会出现版本冲突导致加载失败。
• 版本冗余：很多基础类库（比如System.Runtime这类.NET基础库）不同版本间可能只是小补丁，API完全兼容，强行设置唯一版本只会增加无意义的版本区分。
• 生态兼容性下降：第三方库大多依赖基础库的特定版本范围，每个DLL用唯一版本会导致第三方库兼容性大幅降低，项目无法正常引用。
• 维护成本高：每次构建都修改版本号会让版本管理混乱，排查版本相关问题时难度也会提升。

内容的提问来源于stack exchange，提问作者Shad