【发布时间】：2018-11-08 10:12:11
【问题描述】：
我知道 nuget.org 还没有此功能，但我一直在 nuget 包开发人员网站上搜索发行说明，这比预期花费的时间更长，因为我的 .网络框架项目。 有一个更好的方法吗？也许有人已经这样做并在某处发布了列表？
提前致谢
【问题讨论】：
标签： .net-core nuget nuget-package
【发布时间】：2018-11-08 10:12:11
【问题描述】：
如果您的项目使用带有 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.。请注意，您可以继续使用带有 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 并且没有什么阻止您这样做，那么进行升级是低风险的并且会带来一些好处，例如文件上的合并冲突更少，更容易为您创建的任何包创建 nupkgs维护，并能够在几秒钟内针对 .NET Core 兼容性进行测试。
替代方案：如果您无法或不愿意迁移到基于 SDK 的项目，并且您想检查您的依赖项是否兼容，则使用 dotnet new classlib 创建一个新的 .NET Core 项目，将包引用添加到同一个项目您现有项目使用的包，然后尝试恢复。如果您有一个包含大量项目和/或参考的大型解决方案，只需编写一个小程序以将您的 packages.config/csproj 文件读取为 XML，找到您使用的包的唯一列表，然后编写一个新的基于 SDK 的 csproj 目标.NET Core 以及您刚刚找到的所有包作为包引用。
【讨论】：
如果您将 nuget URL 中的“n”更改为“f”，则它变为 fuget，您将获得软件包目标框架的列表。如果您看到它以 netstandard 版本为目标，那么它将适用于 .NET Core。
【讨论】：