project.json リファレンス

大事な

このコンテンツは非推奨です。 プロジェクトでは PackageReference 形式を使用する必要があります。 project.json プロジェクトを PackageReference に移行方法について説明します。

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 2022 Update 14 の組み込み移行ツールを使用する方法です。

1. Visual Studio で project.json プロジェクトを読み込みます。
2. project.json プロジェクトのソリューション エクスプローラーに移動し、依存関係ノードを見つけます。
3. [Migrate project.json to 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
コンパイル	lib
建てる	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 以外のプラットフォームが dotnetと互換性を持つことが許可されるように project.json に以下を追加しない限り、依存するすべてのパッケージにも 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 がパッケージのグラフを示し、プロジェクト内のすべてのパッケージのバージョン、内容、依存関係を含む場合に生成されるすべての情報のスナップショットが保持されます。 ビルド システムはこれを使用して、プロジェクト自体のローカル パッケージ フォルダーに応じてではなく、プロジェクトのビルド時に関連するグローバルな場所からパッケージを選択します。 これにより、多数の個別の .nuspec ファイルではなく、project.lock.json のみを読み取る必要があるため、ビルドパフォーマンスが向上します。

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