NuGet报“版本冲突”错误是因为多项目/包对同一依赖（如Newtonsoft.Json）的版本范围不兼容，导致扁平化依赖解析失败；需通过Directory.Build.props统一版本、bindingRedirect解决运行时加载问题，并用dotnet list命令精准定位冲突源。
为什么 NuGet 会报“版本冲突”错误
当你在多个项目或包中引用了同一依赖库（比如 Newtonsoft.Json），但各自要求的版本范围不兼容时，dotnet restore 或 Visual Studio 包管理器就会报错，典型提示如：NU1107: Version conflict detected。这不是编译错误，而是还原阶段就卡住——意味着程序根本跑不起来。
根本原因在于：.NET 的依赖解析是“扁平化”的（尤其在 PackageReference 方式下），所有直接/间接依赖最终要收敛到一个具体版本；如果两个上游包分别锁定了 13.0.1 和 12.0.3，且没有共同兼容版本，就无法自动选解。
- 常见诱因：团队里有人手动改了
.csproj中的PackageReference版本，但没同步更新其他项目 - 另一个高发场景：引用了老旧的第三方 SDK（如某银行支付 SDK），它内部硬绑了
System.Net.Http 4.3.4，而你的主项目用的是 .NET 6+ 自带的更高版本 - 注意：.NET Framework 项目用
packages.config时冲突表现更隐蔽（可能只在运行时报FileNotFoundException）
强制统一版本：用 GlobalPackageReference 或 Directory.Build.props
最稳妥的做法不是逐个改项目，而是从构建层统一约束。推荐在解决方案根目录加 Directory.Build.props 文件（MSBuild 自动加载）：
<Project>
<PropertyGroup>
<NewtonsoftJsonVersion>13.0.3</NewtonsoftJsonVersion>
</PropertyGroup>
<ItemGroup>
<GlobalPackageReference Include="Newtonsoft.Json" Version="$(NewtonsoftJsonVersion)" />
</ItemGroup>
</Project>
这样所有子项目都会优先采用这个版本，即使某个 .csproj 写了旧版，也会被覆盖。但要注意：
-
GlobalPackageReference只影响新引入的包，不会降级已存在的高版本引用（需手动删掉原PackageReference） - 如果某个依赖包真的不兼容该统一版本（例如用了已移除的 API），会编译失败，这时得查它的
lib/netX.X/目标框架兼容性 - 别对
Microsoft.*系列包（如Microsoft.Extensions.DependencyInjection）盲目统一——它们有严格的语义化版本策略，跨大版本可能破坏行为
运行时绑定重定向：解决 FileNotFoundException 类型的冲突
有时候还原成功、编译通过，但一运行就崩，错误是：Could not load file or assembly 'xxx, Version=A.B.C.D'。这是典型的运行时加载失败，说明 GAC 或输出目录里实际放的是版本 E.F.G.H，而某个 DLL 在元数据里硬编码引用了 A.B.C.D。
解决方法是在 app.config 或 web.config 里加 bindingRedirect：
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json"
publicKeyToken="30ad4fe6b2a6aeed"
culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-13.0.3.0"
newVersion="13.0.3.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
关键点：
-
oldVersion范围必须覆盖所有可能被引用的旧版（常用0.0.0.0-当前新版） -
publicKeyToken必须准确——可从已安装的 DLL 上用sn -T xxx.dll查 - .NET Core / .NET 5+ 默认不读
.config，这种重定向只对netfx项目有效；Core 项目靠AssemblyLoadContext或发布时的deps.json解决，一般不需要手动配
检查和定位冲突源：用 dotnet list package --include-transitive
别靠猜。在解决方案根目录执行这条命令，能列出每个项目的所有直接/传递依赖及其版本树：
dotnet list YourApp.csproj package --include-transitive
输出里会清晰显示谁拉入了 YamlDotNet 8.1.2，谁又拉了 8.0.0，再顺藤摸瓜看是哪个 NuGet 包带来的。配合 --outdated 还能快速发现可升级项。
容易忽略的一点：有些冲突其实来自工具链本身。比如你装了 dotnet-format 全局工具，它自带一套 Microsoft.CodeAnalysis.*，如果项目也引用同名包但版本不同，可能干扰编译器服务——这类问题得用 dotnet tool list -g 检查并考虑卸载或换用本地工具包。
