重要
此内容已弃用。 项目应使用 PackageReference 格式。 了解如何 将 project.json 项目迁移到 PackageReference。
NuGet 3+ 中使用的 project.json 系统以多种方式影响包作者，如以下部分所述。
影响现有包使用情况的更改
传统的 NuGet 包具备的一些特性并未传递到传递依赖的环境中。
将忽略安装和卸载脚本
依赖项解析中所述的可传递还原模型没有“包安装时间”的概念。 包存在或不存在，但安装包时没有一致的进程。
此外，仅在 Visual Studio 中支持安装脚本。 其他 IDE 必须模拟 Visual Studio 扩展性 API 来尝试支持此类脚本，并且常见编辑器和命令行工具中没有支持。
不支持内容转换
与安装脚本类似，转换在软件包安装时运行，通常情况下不是幂等的。 由于不再有安装时间点，因此不支持 XDT 转换以及类似的功能，如果此类包在传递性方案中使用，则会被忽略。
内容
传统的 NuGet 包传送内容文件，例如源代码和配置文件。 通常在两种情况下使用：
然后将初始文件放入项目中，以便用户以后可以对其进行编辑。 常见示例是默认配置文件。
用作项目中安装的程序集的配套内容文件。 这里的例子是程序集使用的徽标图像。
由于与脚本和转换类似的原因，目前内容支持被禁用，但我们正在设计内容的支持方案。
内容文件仍可携带在包内，当前将被忽略，但最终用户仍可将它们复制到正确的位置。
您可以在此处查看有关带回内容文件的建议之一，并跟踪其进度：https://github.com/NuGet/Home/issues/627。
对包作者的影响
使用上述功能的包必须使用其他机制。 最常见的实用机制是 MSBuild 的目标和属性文件，这些目标和属性文件将继续获得全面支持。 生成系统可以选择选取包中的其他约定。 这是 MSBuild 目标和 Roslyn 分析器支持的实现方式。 可以生成支持 packages.config 和 project.json 方案的目标和分析器的包。
尝试修改项目以便于启动的包通常只适用于非常有限的场景，而应提供自述文件或关于如何使用该包的指导。
大多数现有包不应使用下面所述的包格式。
该格式使本机内容成为首要场景。 这意味着托管程序集依赖于接近硬件的实现，以便在目标平台的基础上，将二进制实现与托管程序集一起交付。 例如，System.IO.Compression 包正在利用这项技术。 https://www.nuget.org/packages/System.IO.Compression
总之，如果上述功能不是绝对必要的，我们建议继续使用现有的包格式，因为此处所述的格式仅受 NuGet 3.x+ 支持。
可以通过填充兼容层来构建在 packages.config 和 project.json 场景中工作的包，但通常更简单的方法是采用传统构建方式，不使用上述不推荐的功能。
3.x 包格式
3.x 包格式允许除 NuGet 2.x 之外的其他几个功能：
定义用于编译的引用程序集和一组用于不同平台/设备上的运行时的实现程序集。 这样，您可以利用特定于平台的 API，同时为消费者提供一个公共的功能接口。 具体而言，这使得编写中间可移植库更容易。
允许包在操作系统或 CPU 架构等平台上调整。
允许将针对特定平台的实现分离到相关配套包中。
将原生依赖项作为核心功能支持。