.NET 5引用Microsoft.AspNetCore.Mvc.NewtonsoftJson构建报NU1202错误

你遇到的NU1202报错根本不是NuGet包或者SDK版本不一致导致的——两台设备虽然装了同版本的.NET SDK，但实际构建时用的运行时标识符（RID）、继承的构建属性完全不一样，才会出现同命令不同结果的情况。

• PATH优先级导致实际调用的SDK架构不一致
  很多人装.NET SDK的时候会同时装x86和x64版本，如果Windows Server 2016设备的系统PATH环境变量里，x86版本的dotnet.exe路径排在x64版本前面，你敲dotnet build时跑的根本不是你以为的x64 SDK。x86架构的.NET 5 SDK在Windows Server 2016环境下，会自动附加win7-x86的兼容RID做包校验；而Windows 10设备上要么默认跑x64 SDK，要么系统版本识别正常，不会附加这个旧版兼容RID，校验逻辑自然不一样。
• 系统注册表异常导致RID推断错误
  .NET SDK判断当前系统对应的RID时，会读注册表里的Windows内核版本号。如果Windows Server 2016设备装过系统优化工具、RDP补丁、安全类组件，把HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion下的主版本号、次版本号改成了Windows 7对应的6.1标识，SDK就会错误判定当前系统是Win7，自动给所有构建绑定win7-x86的RID。Windows 10设备没被改过注册表项，SDK识别到的是正常的10.0内核版本，不会生成这个异常RID，自然不会触发兼容性报错。
• 全局构建配置的强制覆盖
  很多人为了统一部署环境，会在用户根目录、系统全局的MSBuild配置文件夹下放Directory.Build.props文件，硬编码配置比如<RuntimeIdentifier>win7-x86</RuntimeIdentifier>。这个配置会被目录下所有项目自动继承，哪怕你自己项目的.csproj里完全没写相关内容。Windows 10设备没有这类全局配置，构建时不会被强制绑定特定RID，自然校验正常。

你清理NuGet缓存解决不了这个问题的原因很简单：这个错根本不是本地缓存的包损坏导致的，是你构建的目标框架+RID组合本身就不对——哪怕重新拉一遍所有包，还是会按照错误的net5.0/win7-x86组合去做兼容性检查，自然还是会报同一个错。

• 敲dotnet --info，看输出里的SDK安装条目，确认当前实际运行的是哪个路径、哪个架构的dotnet程序
• 直接在命令行敲dotnet build -p:RuntimeIdentifier=强制清空自动推断的RID，如果构建直接通过，就能确认是自动RID推断异常导致的问题
• 打开注册表编辑器，查看HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion路径下的版本数值，确认是不是正常Windows Server 2016对应的10.0.14393版本，有没有被改成Win7对应的6.1版本
• 从用户目录往下逐级排查，看有没有全局的Directory.Build.props、NuGet.Config文件，里面有没有强制写死的运行时配置

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