NetStandard与.NET Core版本依赖问题咨询

嘿，这个问题其实戳中了很多人对NetStandard和.NET Core组件依赖的常见误解，咱们一步步理清楚：

首先纠正核心误解：NetStandard是API规范，但依赖包可能绑定特定.NET Core版本 #

你说得没错，NetStandard本身是一套跨.NET平台的API契约，它的设计目标就是让类库能在多个.NET runtime上运行（比如.NET Core 2.1、.NET Framework 4.6.1等）。你的库是NetStandard 2.0，理论上确实可以在支持它的ASP.NET Core 2.1项目中运行——但问题出在你依赖的Microsoft.Extensions.Options.ConfigurationExtensions包上，而不是NetStandard本身。

关键原因：Microsoft.Extensions.*组件的版本与.NET Core SDK强绑定 #

像Microsoft.Extensions.Options.ConfigurationExtensions这类属于ASP.NET Core基础框架的组件，它们的版本号是和.NET Core SDK版本严格对齐的：

• 2.2版本的包对应.NET Core 2.2 SDK/runtime
• 2.1版本的包对应.NET Core 2.1 SDK/runtime

这些组件内部直接依赖了对应版本的.NET Core runtime API。当你的NetStandard库引用了2.2版本的这个包，在ASP.NET Core 2.1项目中引用时，NuGet会检测到依赖冲突：2.2版本的包需要2.2版本的runtime API，而你的2.1项目提供的是2.1版本的runtime，缺少这些API。为了避免编译/运行时错误，NuGet就会要求你升级项目到2.2版本。

你之前误解的点：混淆了“类库的API兼容性”和“依赖包的版本兼容性” #

你以为NetStandard库不受SDK版本影响，这个想法只对了一半：你的库本身的API是符合NetStandard 2.0的，确实不绑定特定SDK，但它所依赖的第三方包（尤其是Microsoft官方的ASP.NET Core组件）是绑定到特定.NET Core版本的，这就把整个依赖链和2.2版本绑死了。

解决办法 #

针对你的情况，有几个可行的方案：

• 最稳妥的方案：将NetStandard库中Microsoft.Extensions.Options.ConfigurationExtensions的依赖版本降级到2.1.x。NetStandard 2.0完全兼容2.1版本的这个组件，降级后你的库就能在ASP.NET Core 2.1项目中正常引用编译。
• 临时应急方案（不推荐）：在ASP.NET Core 2.1项目的.csproj中添加绑定重定向，强制使用2.2版本的组件。但这可能导致运行时错误，因为2.2版本的组件可能调用了2.1 runtime没有的API。
• 长期解决方案：抽时间将NetStandard库的构建环境迁移到.NET Core 2.1 SDK，并同步将所有相关依赖包升级到2.1版本，确保整个依赖链都和受支持的2.1版本对齐。

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