如何防止安装不完全兼容 .Net Core 2.0 的 NuGet 包？

Question

我知道.Net Core 2有一个兼容性层，可以使用不专门针对.Net Core/Standard 2的Nuget包。这使它可以访问70%的Nuget。非常好-很棒的功能。

我如何防止安装与.Net Core 2/.Net Standard 2不完全兼容的nuget包？或在安装时警告我正在使用shim？

我创建了一个新的.Net Core 2.0项目，并安装了EF 6.1.3（我知道不起作用），但是没有任何东西在安装时阻止或警告它未针对 .Net Standard <= 2。

我很高兴“随便跑” ，但我觉得在将MVC5和EF 6.1.3安装到.Net Core 2应用程序中之前，应该会收到警告。我真的很想防止初级开发人员安装不受支持的软件包等。

我猜想除了Matt Ward的答案之外，我的主要观点是-是否可以在安装时检测某些东西是否实际上与100％兼容，还是我们总是处于需要自行确定软件包是否足够好的情况中。我希望有一种技术机制可以检测缺失的API覆盖范围，并告诉我们该Nuget包可能无法像以前那样操作。所以我想MS说70％的兼容性-如果我尝试安装30％，我希望失败。

- GraemeMiller

Answer 1

在.NET Core 2.0项目中安装Entity Framework 6.1.3时，错误窗口会出现NU1701警告，指出Entity Framework 6.1.3是使用.NET Framework 4.6.1恢复的，并且可能不完全兼容。

您可以在项目中将NU1701警告转换为错误，以便您无法安装任何未明确支持.NET Core 2.0的NuGet包。这可以通过向项目添加WarningAsErrors属性来完成。

<PropertyGroup>
  <OutputType>Exe</OutputType>
  <TargetFramework>netcoreapp2.0</TargetFramework>
  <WarningsAsErrors>NU1701</WarningsAsErrors>
</PropertyGroup>

如果您尝试安装Entity Framework 6.1.3，则还原将失败，更改将被回滚，NuGet包将无法安装。

您还可以将DisableImplicitAssetTargetFallback属性设置为true，这将防止将.NET 4.6.1添加到AssetTargetFallback属性中，在检查NuGet包与.NET Core 2.0项目兼容性时使用该属性。

<PropertyGroup>
  <OutputType>Exe</OutputType>
  <TargetFramework>netcoreapp2.0</TargetFramework>
  <DisableImplicitAssetTargetFallback>true</DisableImplicitAssetTargetFallback>
</PropertyGroup>

- Matt Ward

---

如果Entity Framework所需的所有API都存在，NU1701警告仍然会出现吗？还是它真的是在说这不是针对.Net Standard X的？对我来说，看起来警告只是一条通用消息，如果我针对任何非.NetCoreApp，都会得到这个消息。所以我的意思是 - 我能否检测到某些东西是100％兼容的，并允许它，但不允许不完全兼容的东西？或者我们必须自己决定某些东西是否兼容，没有技术解决方案可以说“是”，这支持我们需要的所有API吗？ - GraemeMiller

它表示EF NuGet包没有与.NET Standard 2.0或.NET Core App 2.0兼容的任何程序集，并假设NuGet包提供的.NET Framework程序集是兼容的。NuGet检查不全面 - 它不会查看程序集并检查其使用的所有API以查看其是否兼容。可能有一些工具可以进行此类检查，但据我所知，NuGet或Visual Studio中没有内置的工具可以完成这项工作。 - Matt Ward

将NU1701警告设置为错误会阻止所有不明确支持.NET Core 2.0但可能可以使用的NuGet包。您需要其他工具来确定它们是否完全兼容。我相信大多数使用最广泛的NuGet包都是如此-微软有关此事公布了一些数字。 - Matt Ward

显然，所有NuGet包中有70%是兼容的 - https://blogs.msdn.microsoft.com/dotnet/2017/08/14/announcing-net-standard-2-0/ - Matt Ward

好的 - 在我看来，这有点可怕。我知道该软件包是通过我的代码库单元/集成测试进行测试的，并且我可以展示它在我需要的场景下工作。但是，如何确定在某些情况下，软件包不会调用不支持的API等，然后在运行时在核心上失败？我只是假设整个过程会更加智能化，NuGet / 代码检查可以告诉我MS认为所有所需的API都存在，并且假设没有实现错误，它应该正常工作。 - GraemeMiller

@GraemeMiller：如果你想要百分之百确定，可以使用.NET可移植性分析器和.NET Standard 2.0配置文件来运行该程序包。它不会告诉你API是否会被调用，只会告诉你程序集中是否包含任何不兼容.NET Standard 2.0的API。 - Tseng

Answer 2

如果您想100％确定，可以对软件包运行.NET Portability Analyzer和.NET Standard 2.0配置文件。

它不会告诉您是否将调用API（并且绝不是自动过程），只会告诉您程序集是否包含任何不兼容.NET Standard 2.0的API。

但是，您也可以仅针对分析器运行应用程序，因为.NET Portability Analyzer应该能够跟随应用程序引用的任何内容并检查这些内容。

更新

您还可以将此构建到您的构建服务器流水线中，以获得更自动化的保证。

The .NET Portability Analyzer Docs.

不需要Visual Studio，只需从https://github.com/Microsoft/dotnet-apiport/releases下载并运行即可

从文档中：

将当前目录分析的命令输入：\...\ApiPort.exe analyze -f . 要分析特定的.dll文件列表，请输入以下命令：\...\ApiPort.exe analyze -f first.dll -f second.dll -f third.dll

<!-- old dotnet tooling/.NET Core 1.x -->
<PackageTargetFallback>netstandard2.0;portable-net45+win8</PackageTargetFallback>
<!-- new dotnet tooling/.NET Core 2.0 -->
<AssetTargetFallback>netstandard2.0;portable-net45+win8</AssetTargetFallback>

通常情况下，你希望它像这样。

<!-- old dotnet tooling/.NET Core 1.x -->
<PackageTargetFallback>$(PackageTargetFallback);dotnet5.6;portable-net45+win8</PackageTargetFallback>
<!-- new dotnet tooling/.NET Core 2.0 -->
<AssetTargetFallback>$(AssetTargetFallback);dotnet5.6;portable-net45+win8</AssetTargetFallback>

$(PackageTargetFallback)会告诉MSBuild保留旧值并将新值附加到其后。但由于$(PackageTargetFallback)可能（现在无法深入查看/挖掘）具有.NET Framework标记，因此您将使用自己的值覆盖它。

此外

鉴于PackageTargetFallback现已弃用，应改用AssetTargetFallback。

- Tseng

---

在还原的过程中，您是否收到任何警告？如果是，您可以在项目设置中将它们转换为错误。 - Tseng

我应该清楚，如果我查看Nuget依赖项视图，我会收到警告 - 我正在尝试防止到达那一步。 - GraemeMiller

@GraemeMiller 我刚试了一下使用 .NetCore 1.1 作为目标的项目，但是出错了，提示 EF 6.3.1 不兼容。请问 .NetCore 1.1 和 2.0 之间有区别吗？还是说有其他选项导致了这个问题？ - Viktor Seifert

@ViktorSeifert .Net Core 2 支持使用兼容性桥接程序，使得 .Net Core 项目可以使用未编译为 .Net 标准的程序集，只要它们支持相应的 API。https://dev59.com/OlcP5IYBdhLWcg3wY5KJ - GraemeMiller

我刚刚意识到PackageTargetFallback已经被弃用，应该使用AssetTargetFallback代替。你可以尝试一下，并反馈是否比PackageTargetFallback更好用。我之所以注意到这一点，是因为我尝试通过命令行构建我的项目时出现了错误，而Visual Studio却没有抱怨任何问题。 - Tseng

Answer 3

据我所知，.NET可移植性分析工具无法百分之百确定不支持安装的平台，例如system.runtime.Loader。在工具分析后，能够确定100%支持框架平台，但并非所有情况都如此。 分析结果截图：分析System.Runtime.Loader

- Smart