我知道nuget.org还没有此功能，但是我一直在nuget软件包开发者网站上搜索发行说明，这比预期的时间长，因为我的上安装了很多nuget软件包。网络框架项目。 有一个更好的方法吗？也许有人已经做到了，并在某个地方发布了清单？
预先感谢
答案 0 :(得分：1)
如果将nuget URL中的'n'更改为'f'，则它变成fuget，您将获得软件包目标框架的列表。如果您看到它以netstandard版本为目标，那么它将与.NET Core一起使用。
答案 1 :(得分：0)
如果您的项目使用的是带有packages.config的“旧”样式的csproj，则第一步是迁移到使用PackageReference。 Here's some docs。如文档所述，packages.config和PackageReference的工作方式之间存在一些差异。如果您受到影响，则会被阻塞，直到可以使用PackageReference来使您的项目起作用。
如果您的项目使用的是带有PackageReference的“旧”样式的csproj（例如，您在上面进行了迁移），请迁移到基于SDK的csproj，以便可以使用dotnet CLI进行构建。 Here's a blog post with details how to do it.。请注意，您可以将Windows .NET Framework与SDK csproj一起使用。尽管基于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，并且没有任何阻碍，那么进行升级是低风险的，并带来了一些好处，例如文件上的合并冲突更少，为您创建的任何软件包更轻松地创建nupkgs维护，并能够在几秒钟内针对.NET Core兼容性进行测试。
替代方法：如果您不能或不愿意迁移到基于SDK的项目，并且想要检查您的依赖项是否兼容，请使用dotnet new classlib创建一个新的.NET Core项目，将包引用添加到现有项目使用的相同软件包，然后尝试还原。如果您有一个包含大量项目和/或引用的大型解决方案，只需编写一个小程序以XML格式读取packages.config / csproj文件，找到您使用的唯一包列表，然后编写一个基于SDK的新的csproj定位.NET Core，其中包含您刚刚找到的所有软件包，作为软件包参考。