能否在同一解决方案中混用.NET Standard 2.0与2.1版本？

核心结论 #

不存在完全禁止跨版本混合引用的硬限制，你遇到的版本不匹配报错，是.NET Standard编译校验规则触发的常规提示，不是框架层面的兼容性阻塞。

报错的底层逻辑 #

.NET Standard的版本兼容有两个不可打破的硬规则：

• 引用方向严格单向：高版本.NET Standard项目可以引用低版本.NET Standard的类库，反向引用会直接报错。比如netstandard2.1项目本来是可以正常加载netstandard2.0编译产物的，但netstandard2.0项目永远引不了netstandard2.1的库——因为2.1版本包含大量2.0没有的API、类型，低版本的运行环境根本没法识别这些内容。
• 你现在遇到的报错，是因为解决方案做整包编译校验时，发现那个服务于.net 4.8的通用工具库，只编译了netstandard2.0的目标产物。而.net 4.8从框架设计上就永远不会实现.netstandard2.1的规范，没有对应2.1目标的编译产物，编译系统自然会提示关联的工具库版本不匹配。

可直接套用的解决方法 #

• 给现有通用工具类库配置多目标编译，不要做单目标绑定
  把原来项目配置里单目标的<TargetFramework>netstandard2.0</TargetFramework>，改成多目标格式<TargetFrameworks>netstandard2.0;netstandard2.1</TargetFrameworks>即可。
  调整后，所有需要兼容.net 4.8的站点、应用会自动匹配工具库的netstandard2.0编译产物，原有运行逻辑完全不受影响；你要切换到netstandard2.1的应用项目，会自动匹配到对应的2.1版本产物，版本不匹配的报错会直接消失。
  注意：只要工具库的源代码没有调用只有netstandard2.1才支持的API（比如原生可空引用类型、Span相关API），两个编译目标可以完全共享同一份代码，不需要拆分独立项目。
• 不需要全局升级时，拆分细粒度的独立类库
  要是你只是某一个业务模块需要用到netstandard2.1的特性，不需要全解决方案跟着升级，就把这部分需要2.1能力的逻辑抽成独立的小类库，目标框架单独设为netstandard2.1即可。原来的老netstandard2.0工具库完全不动，继续服务所有.net 4.8的应用；新抽出来的2.1类库可以正常引用老的2.0工具库，目标应用项目同时引用两个库就可以正常编译。

避坑提醒 #

• 千万别直接把原来单目标netstandard2.0的工具库改成单目标netstandard2.1，改完后所有依赖它的.net 4.8应用会直接编译失败，没有例外。
• 如果你的项目还是老式的packages.config格式，先把所有关联项目升级成SDK风格格式，不然跨版本引用、多目标编译的逻辑会触发很多无意义的校验报错。

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