справочник по project.json

Важный

Это содержимое устарело. Проекты должны использовать форматы PackageReference. Узнайте, как перенести проект project.json в PackageReference. Visual Studio 2026 автоматически переносит project.json во время загрузки решения. Пакет SDK для .NET 10 и NuGet.exe 7.0 не поддерживает проекты project.json.

NuGet 3.x

Файл project.json поддерживает список пакетов, используемых в проекте, который называется форматом управления пакетами. Он заменяет packages.config, но в свою очередь заменен PackageReference с NuGet 4.0+.

Файл project.lock.json (описано ниже) также используется в проектах, использующих project.json.

project.json имеет следующую базовую структуру, где каждый из четырех объектов верхнего уровня может иметь любое количество дочерних объектов:

{
    "dependencies": {
        "PackageID" : "{version_constraint}"
    },
    "frameworks" : {
        "TxM" : {}
    },
    "runtimes" : {
        "RID": {}
    },
    "supports" : {
        "CompatibilityProfile" : {}
    }
}

Перенос project.json в PackageReference

Миграция между project.json и PackageReference проста.

Автоматическая миграция в Visual Studio 2026

Visual Studio 2026 и более поздних версий автоматически переносит проекты project.json в PackageReference при открытии решения, содержащего проекты project.json. Миграция происходит во время загрузки решения:

Откройте решение, содержащее проекты project.json в Visual Studio 2026 или более поздней версии.
Visual Studio автоматически обнаруживает project.json файлы и переносит их в формат PackageReference.
Чтобы проверить состояние миграции, откройте окно вывода и выберите "Показать выходные данные" в диспетчере пакетов. Вы увидите сообщения, такие как "Перенос проекта project.json..." за которым следует "Миграция выполнена успешно" для каждого проекта. Все ошибки будут отображаться в списке ошибок.
Резервная копия исходного файла проекта и project.json файла создается в Backup папке в корневом каталоге проекта.
Миграция преобразует все зависимости пакета в формат PackageReference в файле проекта.

Миграция вручную в Visual Studio 2022

Для Visual Studio 2022 и более ранних версий можно использовать встроенный перенос:

Загрузите проект project.json в Visual Studio.
Перейдите в обозреватель решений проекта project.json и найдите узел зависимостей.
Щелкните правой кнопкой мыши и выберите Migrate project.json to PackageReference...

миграция из project.json в PackageReference

Альтернативные методы миграции

Кроме того, можно использовать средство командной строки dotnet migration или выполнить миграцию вручную, взяв все содержимое из файла project.json и заменив его эквивалентным синтаксисом PackageReference.

Зависимости

Выводит список зависимостей пакета NuGet проекта в следующей форме:

"PackageID" : "version_constraint"

Например:

"dependencies": {
    "Microsoft.NETCore": "5.0.0",
    "System.Runtime.Serialization.Primitives": "4.0.10"
}

В разделе dependencies диалоговое окно диспетчера пакетов NuGet добавляет зависимости пакетов в проект.

Идентификатор пакета соответствует идентификатору пакета в nuget.org, аналогично идентификатору, используемому в консоли диспетчера пакетов: Install-Package Microsoft.NETCore.

При восстановлении пакетов ограничение версии "5.0.0" подразумевает >= 5.0.0. То есть, если на сервере недоступна версия 5.0.0, но 5.0.1, NuGet устанавливает версию 5.0.1 и предупреждает вас об обновлении. В противном случае NuGet выбирает самую низкую возможную версию на сервере, соответствующую ограничению.

Дополнительные сведения о правилах разрешения зависимостей см. в .

Управление ресурсами зависимостей

Какие ресурсы из зависимостей управляются проектом верхнего уровня, указывая набор тегов с разделителями-запятыми в include и exclude свойства ссылки на зависимость. Теги перечислены ниже.

Тег include/Exclude	Затронутые папки целевого объекта
contentFiles	Содержание
Среды выполнения	Среда выполнения, ресурсы и платформыAssemblies
компилировать	lib
строить	сборка (props и целевые объекты MSBuild)
родной	родной
никакой	Нет папок
все	Все папки

Теги, указанные с exclude, имеют приоритет над указанными include. Например, include="runtime, compile" exclude="compile" совпадает с include="runtime".

Например, чтобы включить build и native папки зависимостей, используйте следующее:

{
  "dependencies": {
    "packageA": {
      "version": "1.0.0",
      "include": "build, native"
    }
  }
}

Чтобы исключить content и build папок зависимости, используйте следующее:

{
  "dependencies": {
    "packageA": {
      "version": "1.0.0",
      "exclude": "contentFiles, build"
    }
  }
}

Рамки

Перечисляет платформы, на которые выполняется проект, например net45, netcoreapp, netstandard.

"frameworks": {
    "netcore50": {}
    }

В разделе frameworks допускается только одна запись. (Исключением является project.json файлов для проектов ASP.NET, которые создаются с нерекомендуемой цепочкой инструментов DNX, что позволяет использовать несколько целевых объектов.)

Среды выполнения

Выводит список операционных систем и архитектур, на которые работает ваше приложение, например win10-arm, win8-x64, win8-x86.

"runtimes": {
    "win10-arm": { },
    "win10-arm-aot": { },
    "win10-x86": { },
    "win10-x86-aot": { },
    "win10-x64": { },
    "win10-x64-aot": { }
}

Пакет, содержащий PCL, который может выполняться в любой среде выполнения, не требуется указывать среду выполнения. Это также должно быть верно для любых зависимостей, в противном случае необходимо указать среды выполнения.

Поддерживает

Определяет набор проверок зависимостей пакета. Вы можете определить, где будет выполняться PCL или приложение. Определения не являются строгими, так как код может работать в другом месте. Но при указании этих проверок nuGet проверяет, удовлетворены ли все зависимости на перечисленных TxMs. Ниже приведены примеры значений: net46.app, uwp.10.0.appи т. д.

Этот раздел следует заполнять автоматически при выборе записи в диалоговом окне "Переносимая библиотека классов".

"supports": {
    "net46.app": {},
    "uwp.10.0.app": {}
}

Импорт

Импорты предназначены для предоставления пакетам, которые используют dotnet TxM для работы с пакетами, которые не объявляют dotnet TxM. Если проект использует dotnet TxM, то все пакеты, от которых вы зависите, также должны иметь dotnet TxM, если в project.json не добавлено следующее, чтобы разрешить совместимость платформ, отличных от dotnet, с dotnet:

"frameworks": {
    "dotnet": { "imports" : "portable-net45+win81" }
}

Если вы используете dotnet TxM, система проектов PCL добавляет соответствующую инструкцию imports на основе поддерживаемых целевых объектов.

Различия от переносимых приложений и веб-проектов

Файл project.json, используемый NuGet, представляет собой подмножество, которое найдено в проектах ASP.NET Core. В ASP.NET Core project.json используется для метаданных проекта, сведений о компиляции и зависимостях. При использовании в других системах проектов эти три вещи разделяются на отдельные файлы и project.json содержат меньше информации. К заметным различиям относятся:

В разделе frameworks может быть только одна платформа.
Файл не может содержать зависимости, параметры компиляции и т. д., отображаемые в файлах DNX project.json. Учитывая, что существует только одна платформа, она не имеет смысла вводить зависимости для конкретной платформы.
Компиляция обрабатывается MSBuild, поэтому параметры компиляции, препроцессор определяет и т. д. являются частью файла проекта MSBuild, а не project.json.

В NuGet 3+разработчики не должны вручную изменять project.json, так как пользовательский интерфейс диспетчера пакетов в Visual Studio управляет содержимым. Это сказало, вы, безусловно, можете изменить файл, но необходимо создать проект, чтобы запустить восстановление пакета или вызвать восстановление другим способом. См. восстановления пакетов.

project.lock.json

Файл project.lock.json создается в процессе восстановления пакетов NuGet в проектах, использующих project.json. Он содержит моментальный снимок всех сведений, создаваемых в виде NuGet, содержит график пакетов и включает версию, содержимое и зависимости всех пакетов в проекте. Система сборки использует это для выбора пакетов из глобального расположения, которое относится при создании проекта, а не в зависимости от локальной папки пакетов в самом проекте. Это приводит к более быстрой производительности сборки, так как необходимо читать только project.lock.json вместо множества отдельных .nuspec файлов.

project.lock.json автоматически создается при восстановлении пакета, поэтому его можно исключить из системы управления версиями, добавив его в файлы .gitignore и .tfignore (см. пакеты исистемы управления версиями. Однако если включить его в систему управления версиями, журнал изменений отображает изменения в зависимостях, разрешенных с течением времени.

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2025-10-15