次の方法で共有

project.json リファレンス

大事な

このコンテンツは非推奨です。 プロジェクトでは PackageReference 形式を使用する必要があります。 project.json プロジェクトを PackageReference に移行方法について説明します。 Visual Studio 2026 では、ソリューションの読み込み時に project.json が自動的に移行されます。 .NET 10 SDK および NuGet.exe 7.0 では、project.json プロジェクトはサポートされていません。

NuGet 3.x

project.json ファイルには、パッケージ管理形式と呼ばれるプロジェクトで使用されるパッケージの一覧が保持されます。 packages.config に置き換えられますが、次に NuGet 4.0 以降の PackageReference に置き換えられます。

project.lock.json ファイル(後述)は、project.jsonを採用するプロジェクトでも使用されます。

project.json には次の基本構造があり、4 つの最上位オブジェクトのそれぞれに任意の数の子オブジェクトを含めることができます。

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

project.json を PackageReference に移行する

project.json と PackageReference の間の移行は簡単です。

Visual Studio 2026 での自動移行

Visual Studio 2026 以降では、project.json プロジェクトを含むソリューションを開くと、project.json プロジェクトが PackageReference に自動的に移行されます。 移行は、ソリューションの読み込み時に行われます。

  1. Visual Studio 2026 以降で、project.json プロジェクトを含むソリューションを開きます。
  2. Visual Studio は project.json ファイルを自動的に検出し、PackageReference 形式に移行します。
  3. 移行の状態を確認するには、[ 出力] ウィンドウ を開き、[パッケージ マネージャー] から [出力の表示] を選択します。 "project.json プロジェクトの移行... " のようなメッセージが表示されます。次に、各プロジェクトの "移行に成功しました" が続きます。 エラーはエラー一覧に表示されます。
  4. 元のプロジェクト ファイルと project.json ファイルのバックアップは、プロジェクト ディレクトリのルートにある Backup フォルダーに作成されます。
  5. 移行により、すべてのパッケージ依存関係がプロジェクト ファイル内の PackageReference 形式に変換されます。

Visual Studio 2022 での手動移行

Visual Studio 2022 以前の場合は、組み込みの移行ツールを使用できます。

  1. Visual Studio で project.json プロジェクトを読み込みます。
  2. project.json プロジェクトのソリューション エクスプローラーに移動し、依存関係ノードを見つけます。
  3. 右クリックして Migrate project.json to PackageReference...

project.json から PackageReference への移行

代替の移行方法

または、 dotnet migrate コマンド ライン ツールを使用するか、project.json ファイルからすべてのコンテンツを取得し、同等の PackageReference 構文に置き換えることで、手動で移行を行うことができます。

依存 関係

プロジェクトの NuGet パッケージの依存関係を次の形式で一覧表示します。

"PackageID" : "version_constraint"

例えば：

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

dependencies セクションでは、[NuGet パッケージ マネージャー] ダイアログでパッケージの依存関係がプロジェクトに追加されます。

パッケージ ID は、パッケージ マネージャー コンソールで使用される id と同じ、nuget.org 上のパッケージの ID に対応しています: 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 コンテンツ
ランタイム ランタイム、リソース、および FrameworkAssemblies
コンパイル ライブラリ
ビルド build (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 セクションでは、1 つのエントリのみが許可されます。 (例外は、非推奨の DNX ツール チェーンを使用してビルドされる ASP.NET プロジェクトのファイルを project.json します。これにより、複数のターゲットが許可されます)。

ランタイム

win10-arm、win8-x64、win8-x86など、アプリが実行されているオペレーティング システムとアーキテクチャを一覧表示します。

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

任意のランタイムで実行できる PCL を含むパッケージでは、ランタイムを指定する必要はありません。 これはすべての依存関係にも当てはまる必要があります。それ以外の場合は、ランタイムを指定する必要があります。

楨

パッケージの依存関係のチェックのセットを定義します。 PCL またはアプリを実行する場所を定義できます。 コードは他の場所で実行できる可能性があるため、定義は制限されていません。 ただし、これらのチェックを指定すると、一覧表示されている TxMs ですべての依存関係が満たされていることを NuGet で確認できます。 この値の例は、net46.app、uwp.10.0.appなどです。

このセクションは、[ポータブル クラス ライブラリ ターゲット] ダイアログでエントリを選択すると自動的に設定されます。

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

インポート

インポートは、dotnet TxM を使用するパッケージが dotnet TxM を宣言しないパッケージで動作できるように設計されています。 プロジェクトで dotnet TxM を使用している場合は、dotnet 以外のプラットフォームが project.jsonと互換性を持つことが許可されるように dotnet に以下を追加しない限り、依存するすべてのパッケージにも dotnet TxM が必要です。

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

dotnet TxM を使用している場合、PCL プロジェクト システムは、サポートされているターゲットに基づいて適切な imports ステートメントを追加します。

ポータブル アプリと Web プロジェクトとの違い

NuGet で使用される project.json ファイルは、ASP.NET Core プロジェクトで見つかったサブセットです。 ASP.NET Core project.json は、プロジェクトのメタデータ、コンパイル情報、依存関係に使用されます。 他のプロジェクト システムで使用する場合、これら 3 つの要素は個別のファイルに分割され、project.json に含まれる情報が少なくなります。 主な違いは次のとおりです。

  • frameworks セクションには 1 つのフレームワークしか存在できません。

  • このファイルには、DNX project.json ファイルに表示される依存関係、コンパイル オプションなどを含めることはできません。 1 つのフレームワークしか存在できないことを考えると、フレームワーク固有の依存関係を入力しても意味がありません。

  • コンパイルは MSBuild によって処理されるため、コンパイル オプション、プリプロセッサ定義などは、すべて MSBuild プロジェクト ファイルの一部であり、project.jsonされません。

NuGet 3 以降では、Visual Studio のパッケージ マネージャー UI がコンテンツを操作するため、開発者は project.jsonを手動で編集する必要はありません。 ただし、ファイルは確実に編集できますが、プロジェクトをビルドしてパッケージの復元を開始するか、別の方法で復元を呼び出す必要があります。 パッケージ 復元を参照してください。

project.lock.json

project.lock.json ファイルは、project.jsonを使用するプロジェクトで NuGet パッケージを復元するプロセスで生成されます。 NuGet がパッケージのグラフを示し、プロジェクト内のすべてのパッケージのバージョン、内容、依存関係を含む場合に生成されるすべての情報のスナップショットが保持されます。 ビルド システムはこれを使用して、プロジェクト自体のローカル パッケージ フォルダーに応じてではなく、プロジェクトのビルド時に関連するグローバルな場所からパッケージを選択します。 これにより、多数の個別の project.lock.json ファイルではなく、.nuspec のみを読み取る必要があるため、ビルドパフォーマンスが向上します。

project.lock.json はパッケージの復元時に自動的に生成されるため、.gitignore ファイルや .tfignore ファイルに追加することで、ソース管理から省略できます (「パッケージとソース管理のを参照してください。 ただし、ソース管理に含める場合、変更履歴には、時間の経過と同時に解決された依存関係の変更が表示されます。

  • Last updated on