不使用GAC时，.NET项目是否仍需关注AssemblyVersion？

核心结论：在不使用GAC的.NET Core/5/6+项目中，固定AssemblyVersion为1.0.0.0大部分场景下没问题，但仍有少数场景需要留意AssemblyVersion的作用。

你当前做法的合理性 #

你通过NuGet包遵循语义化版本管理、不依赖GAC的思路完全没问题。很多开发团队确实选择固定AssemblyVersion，把NuGet版本作为唯一的对外版本标识——毕竟.NET Core+的依赖机制默认优先加载本地目录的DLL，AssemblyVersion不会像传统.NET Framework那样影响GAC加载逻辑，因此不会出现核心的版本冲突问题。

需要关注AssemblyVersion的场景 #

即使不用GAC，以下场景中AssemblyVersion仍会发挥作用：

• 强签名程序集的插件/扩展场景：如果你的库是强签名的，某些插件系统、依赖注入框架可能会通过AssemblyVersion来识别程序集版本。若始终用1.0.0.0，更新插件后，框架可能无法区分新旧版本，导致加载错误或逻辑冲突。
• 调试与诊断：排查生产问题时，dump文件、日志里的程序集元数据会包含AssemblyVersion。如果所有版本的程序集都用同一个AssemblyVersion，你没法直接通过版本号快速定位对应的NuGet版本，增加排查成本。
• 反射或序列化场景：部分反射逻辑、自定义序列化器会读取AssemblyName.Version做逻辑判断，若固定版本，可能触发意料之外的兼容性问题（虽然这类场景比较少见）。

可选的优化方案 #

如果想兼顾简洁性和灵活性，可以考虑：

• 把AssemblyVersion和NuGet版本的主版本号对齐，比如NuGet版本是3.2.1，AssemblyVersion设为3.0.0.0。这样既保留了版本区分能力，又不用频繁变更AssemblyVersion（避免强签名带来的重新签名、绑定重定向等麻烦）。
• 用MSBuild的Directory.Build.props统一配置版本字段，自动同步AssemblyVersion的部分内容和NuGet版本，减少手动维护的工作量。比如：

  <PropertyGroup>
    <AssemblyVersion>$(MajorVersion).0.0.0</AssemblyVersion>
    <FileVersion>$(NuGetVersion)</FileVersion>
    <InformationalVersion>$(NuGetVersion)</InformationalVersion>
  </PropertyGroup>
  

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