c# - ASP.NET:由Nuget引起的.NET Framework/Standard/Core DLL冲突。 “您必须添加对程序集System.Runtime的引用...”

Question

我们有一个ASP.NET .NET Framework 4.7.2项目。不幸的是，我们要引用较新的Nugets，它不可避免地拖入.NET Standard，或者更糟的是Core。每当我们想要包含一个新的Nuget时，就像在该项目中玩俄罗斯轮盘赌一样。大多数情况下，它将产生以下版本：

You must add a reference to assembly 'System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.

今天，它是在引用.NET Standard项目后在视图编译期间发生的。

由于存在.NET Framework，Standard或Core中的多个System.Runtime DLL，而Visual Studio无法确定将哪个文件夹放入bin文件夹。通常，它在GAC中默认为Framework。

解决方案失败：<dependentAssembly>

我们尝试了各种方法，主要是在web.config中使用<dependentAssembly>：

  <dependentAssembly>
    <assemblyIdentity name="System.Runtime" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.2.0.0" />
  </dependentAssembly>

但是，这导致在我们的依赖项注入设置过程中，项目在运行时崩溃，同时要求System.Runtime的多个版本：

FileNotFoundException: Could not load file or assembly 'System.Runtime, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.

和

FileNotFoundException: Could not load file or assembly 'System.Runtime, Version=4.0.20.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.

失败的Hacky解决方案： <dependentAssembly>并在生成后复制DLL

我们将使用上面的方法，然后将我们手动选择的System.Runtime DLL复制到构建后的bin文件夹中。一个可怕的解决方案，在本地效果很好，但是炸毁了生产，导致找不到各种DLL。

越来越难的解决方案：完全避免使用.NET Standard和Core

我们为此一直苦苦挣扎了一个星期，而在其他项目中，苦苦挣扎了几个月。每次我们遇到它，都需要几天的时间来解决。我们发现的唯一明确的解决方案是避免使用需要.NET Standard或Core的Nuget。但这每天变得越来越难。

不可行的解决方案：PackageReference，或升级到.NET Core

据说，引用包的最新方法PackageReference通常可以解决此问题。但是.NET Framework 4.7.2（仍由Microsoft积极支持）上的ASP.NET不支持此功能，因为ASP.NET Nuget包通常具有在安装时执行的脚本，而PackageReference不支持这些脚本。否则，我们需要将网站升级到.NET Core。我们已经运行了分析器，它说我们必须重写15％的站点，这在当时是不可接受的。

失败的解决方案：将所有内容缓慢移出.NET Framework 4.7.2 ASP.NET项目

我们认为我们会很狡猾，然后开始将我们的库转换为.NET Standard。
 新功能和缓慢的旧功能将被放入使用PackageReference的.NET标准库中，希望避免DLL地狱。不幸的是，在这个实验的大约一天之后，我们回到了第一个问题，因为仍然在.NET Framework 4.7.2上的ASP.NET项目是整个解决方案的根源。实际上，很奇怪的是，我们试图撤消了看似引起碰撞的最新更改，尽管进行了清理和重建，但它似乎是永久性的。老实说，不管它是否奏效，似乎都是幸运的。运气似乎是在考虑具有类似问题的另一种解决方案，其中一个开发人员的计算机可以运行该解决方案，但是另一台计算机不能运行，或者本地部署可以运行，而生产部署则不能。

失败的解决方案：RestoreProjectStyle

当然，我们不能孤单。找到了解决Google问题的方法花了很长时间，但是我们终于找到了同样问题的其他人。这可能是最好的例子： https://github.com/dotnet/sdk/issues/747

我们尝试将 <RestoreProjectStyle>PackageReference</RestoreProjectStyle>添加到我们的ASP.NET项目中，但这实际上似乎使情况变得更糟，即使在还原更改，清除，

失败的解决方案：通过 Assembly.Load并排

我们尝试 Assembly systemRuntime = Assembly.Load("System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a");尝试并排加载两个System.Runtime，但是这没有影响。加载视图后，它仍然显示：

CS0012: The type 'System.Object' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.

有没有一种方法可以引用程序集进行查看时编译？

结论

我已经在.NET Framework世界上呆了很长时间了，所以Visual Studio 2019和.NET Standard / Core对我来说还很新。但是，即使与退伍军人进行了讨论，他们似乎还是说避免问题是最好的解决方案。

否则，我们将进入超级骇客解决方案，例如在初始化时手动加载DLL（可能我们接下来将尝试）。

Answer 1

尽管我在很多地方都没有看到System.Runtime，但是目前，加载视图时它正在爆炸。

我几乎不知道，显然，视图引擎不一定使用与主项目相同的程序集！请参阅另一篇文章中有关如何将程序集添加到视图引擎的答案：https://stackoverflow.com/a/57350759/2589506