在没有 nuget.org 的情况下，确定 nuget 包是否与 .net core 兼容的最佳方法是什么？

Question

我知道 nuget.org 还没有这个功能，但我一直在 nuget 包开发者网站上搜索发行说明，这比预期的要长，因为我在我的 .net 框架项目上安装了很多 nuget 包. 有一个更好的方法吗？也许有人已经完成并在某处发布了列表？

提前致谢

Answer 1

如果您将 nuget URL 中的“n”更改为“f”，使其变为fuget，您将获得该包针对哪些框架的列表。如果您看到它针对某个netstandard版本，那么它将适用于 .NET Core。

Answer 2

如果您的项目使用带有packages.config的“旧”样式csproj，则第一步是迁移到使用PackageReference。这是一些文档。正如文档所说，packages.config 和 PackageReference 的工作方式之间存在一些差异。如果您受到影响，您将被阻止，直到您可以使您的项目与 PackageReference 一起使用。

如果您的项目使用带有 PackageReference 的“旧”样式 csproj（例如您执行了上面的迁移），则迁移到基于 SDK 的 csproj，以便您可以使用 dotnet CLI 进行构建。这是一篇博客文章，详细介绍了如何操作。。请注意，您可以继续使用带有 SDK csproj 的 Windows .NET Framework。虽然基于SDK的csproj与.NET Core同时出现，但新的项目风格并不一定要使用.NET Core。如果您的项目是类库或控制台应用程序，那绝对没问题，否则您需要研究项目类型是否与 SDK 项目兼容。

一旦您的 .NET Framework 项目与 SDK 项目一起使用，请将 更改TargetFramework为 netcoreapp 或 netstandard，或者您可以通过更改为 来对您的项目进行多目标TargetFramework，TargetFrameworks并使用分号分隔的要定位的 TFM 列表。例如<TargetFrameworks>net461;netcoreapp2.1</TargetFrameworks>。然后只需运行dotnet restore，如果您使用的任何包与 .NET Core 不兼容，恢复将失败，您只需恢复到仅目标 .NET Framework。

综上所述，一旦您的项目使用基于 SDK 的 csproj，需要 10 秒的时间来测试您的依赖项是否与 .NET Standard/.NET Core 兼容。如果您的项目尚未使用基于 SDK 的 csproj，您可以撤消对 csproj 中 TargetFramework(s) 行的更改，并继续您的生活，直到下次再次测试。如果您还没有使用基于 SDK 的 csproj 并且没有任何东西阻止您这样做，那么升级的风险很低，并且会带来一些好处，例如文件上的合并冲突更少，为您的任何包创建 nupkg 变得更容易维护，并能够在几秒钟内测试 .NET Core 兼容性。

替代方案：如果您无法或不愿意迁移到基于 SDK 的项目，并且想要检查依赖项是否兼容，请使用dotnet new classlib创建新的 .NET Core 项目，将包引用添加到现有项目使用的相同包中，然后尝试恢复。如果您有一个包含大量项目和/或引用的大型解决方案，只需编写一个小程序来以 XML 形式读取您的packages.config/csproj 文件，找到您使用的包的唯一列表，然后编写一个新的基于 SDK 的 csproj 定位.NET Core，其中包含您刚刚找到的所有包作为包引用。