.net - 让 .NET Framework 项目引用 .NET Standard 程序集需要什么？

Question

我有一个针对 .NET Framework 4.6.2 构建的项目。它的依赖项之一是针对 .NET Standard 2.0 构建的程序集。

它之前在我的旧电脑上构建得很好，但现在我有一个我正在设置的新开发系统，当我尝试运行构建时，使用相同版本的相同工具，我得到了一个关于引用一堆在 .NET Core 中流行的小型单命名空间程序集的 Netstandard DLL 的几十个错误。例如:

The primary reference "Foo" could not be resolved because it has an indirect dependency on the framework assembly "netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" which could not be resolved in the currently targeted framework. ".NETFramework,Version=v4.6.2". To resolve this problem, either remove the reference "Foo" or retarget your application to a framework version which contains "netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51". (MSB3268)

如果我从 GAC 明确添加对 Netstandard 2.0 的项目引用，错误将变为:

The primary reference "netstandard", which is a framework assembly, could not be resolved in the currently targeted framework. ".NETFramework,Version=v4.6.2". To resolve this problem, either remove the reference "netstandard" or retarget your application to a framework version which contains "netstandard". (MSB3267)

同样，这个在旧系统上构建(并且仍然构建)没有错误，我正在尝试在完全相同的 IDE 和编译器上构建项目而不进行任何更改。所以我只能假设我缺少需要在我的开发系统上安装的东西，但我不太确定它是什么。

有没有人遇到过这个？我在这里发现了一些关于尝试从 C# .NET Framework 项目引用 Netstandard 程序集的其他问题，显然由于一些与 Roslyn 相关的细节，这很棘手，但我实际上在我的 NET Framework 项目中使用 Boo 语言，所以这些问题都不是特别相关，而且它以前工作得很好。

感觉应该有一个非常简单的答案，如果我知道我忽略了什么细节......

Answer 1

.NET 团队一直强烈建议迁移到 net472，因为 plethora of issues使用工具链尝试将 .NET Standard 2.0 支持改进到 net461–net471。如果您可以选择升级，那将节省大量时间。 .NET Framework 4.7.2 还具有不需要 dozens of shim DLLs 的附带好处出现在您的 bin 输出中，当然，任何 .NET Framework 升级都会带来一些小的增强。 (发行说明:net47、net471、net472。)

https://twitter.com/terrajobst/status/1031999730320986112 :

Sorry but we messed up. We tried to make .NET Framework 4.6.1 retroactively implement .NET Standard 2.0. This was a mistake as we don't have a time machine and there is a tail of bugs. If you want to consume .NET Standard 1.5+ from .NET Framework, I recommend to be on 4.7.2.

Note that that this has nothing to do with missing APIs (although .NET Framework 4.6.1 misses about 100 APIs). It's all about binding policy, assembly identities, and treatment of framework assemblies in tooling (MSBuild, ClickOnce, test runners etc).

The lesson learned here is simple: once shipped, a given version of a .NET implementation must not change the support level of .NET Standard. IOW, the supported .NET Standard number is an immutable property. Supporting a higher version requires shipping a new version.