次の方法で共有

一般的な NuGet 構成

  • [アーティクル]

NuGet の動作は、1 つ以上の config (XML) ファイルの設定を総合して決まります。ファイルは、ソリューション (ソリューションが使用されていない場合はプロジェクト) レベルや、ユーザー レベル、コンピューター全体レベルで作成できます。

構成ファイルの場所と使用

範囲 NuGet.Config ファイルの場所 説明
解決方法 現在のフォルダー (ソリューション フォルダーとも呼ばれる) またはドライブのルートまでの任意のフォルダー。 ソリューション フォルダーでは、設定はサブフォルダー内のすべてのプロジェクトに適用されます。 構成ファイルをプロジェクト フォルダーに置いた場合、そのプロジェクトには影響しないことに注意してください。 コマンド ラインでプロジェクトを復元すると、プロジェクトのディレクトリがソリューション ディレクトリとして扱われ、プロジェクトとソリューションの復元時の動作が異なる可能性があります。
User Windows: %appdata%\NuGet\NuGet.Config
Mac/Linux: ~/.config/NuGet/NuGet.Config または ~/.nuget/NuGet/NuGet.Config (ツールによって異なります)
すべてのプラットフォームで、追加の構成がサポートされています。 ツールでこれらの構成を編集することはできません。
Windows: %appdata%\NuGet\config\*.Config
Mac または Linux: ~/.config/NuGet/config/*.config または ~/.nuget/config/*.config		 設定はすべての操作に適用されますが、ソリューション レベルの設定によってオーバーライドされます。
コンピューター Windows: %ProgramFiles(x86)%\NuGet\Config
Mac/Linux: 既定では /etc/opt/NuGet/Config (Linux) または /Library/Application Support (Mac)。 $NUGET_COMMON_APPLICATION_DATA が null 値でも空でもない場合は、$NUGET_COMMON_APPLICATION_DATA/NuGet/Config		 設定はそのコンピューターでのすべての操作に適用されますが、ユーザー レベルまたはソリューション レベルの設定によってオーバーライドされます。

Note

Mac/Linux では、ユーザー構成ファイルの場所はツールによって異なります。 .NET CLI では ~/.nuget/NuGet フォルダーが使用され、Mono では ~/.config/NuGet フォルダーが使用されます。

Mac/Linux では、ユーザー レベルの構成ファイルの場所はツールによって異なります

Mac/Linux では、ユーザー構成ファイルの場所はツールによって異なります。 ほとんどのユーザーは、~/.nuget/NuGet フォルダーの中にあるユーザー構成ファイルを検索するツールを使用できます。 ~/.config/NuGet フォルダーの中にあるユーザー構成ファイルを探すツールは、次のようなものがあります。

  • Mono
  • NuGet.exe
  • Visual Studio 2019 for Mac (バージョン 16.7 以前)
  • Visual Studio 2022 for Mac (およびそれ以降のバージョン) は、従来の Mono プロジェクトで作業する場合にのみ使用できます。

使用するツールに両方の場所が含まれている場合は、次の手順に従って統合して、ユーザー レベルの構成ファイルを 1 つだけ操作することを検討してください。

  1. 2 つのユーザー レベルの構成ファイルの内容を確認し、目的のファイルを ~/.nuget/NuGet フォルダーの下に保持します。
  2. シンボリック リンクを~/.nuget/NuGet から ~/.config/NuGet に設定します。 例: bash コマンドを実行する：ln -s ~/.nuget/NuGet ~/.config/NuGet。

以前のバージョンの NuGet に関する注意事項:

  • NuGet 3.3 以前では、ソリューション全体の設定用に .nuget フォルダーが使われていました。 このフォルダーは、NuGet 3.4 以降では使用されません。
  • NuGet 2.6 から 3.x では、Windows でのコンピューター レベルの構成ファイルは %ProgramData%\NuGet\Config[\{IDE}[\{Version}[\{SKU}]]]\NuGet.Config にありました。{IDE} には VisualStudio を使用でき、{Version} は Visual Studio のバージョン (14.0 など)、{SKU} は Community、Pro、または Enterprise です。 設定を NuGet 4.0 以降に移行するには、単に構成ファイルを %ProgramFiles(x86)%\NuGet\Config にコピーします。 Linux の以前の場所は /etc/opt、Mac の以前の場所は /Library/Application Support でした。

構成設定の変更

NuGet.Config ファイルは、NuGet の構成設定に関するトピックで説明されているように、キーと値のペアを含む単純な XML テキスト ファイルです。

設定は、NuGet CLI の config コマンドを使って管理します。

  • 既定では、変更はユーザー レベルの構成ファイルに対して行われます。 (Mac/Linux では、ユーザー レベルの構成ファイルの場所はツールによって異なります)
  • 別のファイルの設定を変更するには、-configFile スイッチを使います。 その場合は、任意のファイル名を使うことができます。
  • キーは常に大文字と小文字が区別されます。
  • コンピューター レベルの設定ファイルの設定を変更するには、特権の昇格が必要です。

警告

任意のテキスト エディターでファイルを変更できますが、NuGet (v3.4.3 以降) では、構成ファイルに正しくない形式の XML (タグの不一致、無効な引用符など) が含まれると、警告なしに構成ファイル全体が無視されます。 このため、設定の管理には nuget config を使うことをお勧めします。

値の設定

Windows:

# Set globalPackagesFolder in the user-level config file
dotnet nuget config set globalPackagesFolder "C:\packages"

# Set repositoryPath (available for packages.config only) in the user-level config file
dotnet nuget config set repositoryPath "C:\packages"

# Set repositoryPath in solution-level files
dotnet nuget config set repositoryPath "C:\packages" --configfile "C:\my.config"
dotnet nuget config set repositoryPath "c:\packages" --configfile "..\..\my.config"

# Set repositoryPath in the computer-level file (requires elevation)
dotnet nuget config set repositoryPath "c:\packages" --configfile "%appdata%\NuGet\NuGet.Config"

Mac/Linux:

# Set globalPackagesFolder in the user-level config file
dotnet nuget config set globalPackagesFolder /home/packages

# Set repositoryPath (available for packages.config only) in the user-level config file
dotnet nuget config set repositoryPath /home/packages

# Set repositoryPath in solution-level files
dotnet nuget config set repositoryPath /home/projects/packages --configfile /home/my.Config
dotnet nuget config set repositoryPath /home/packages --configfile home/myApp/NuGet.Config

# Set repositoryPath in the computer-level file (requires elevation)
dotnet nuget config set repositoryPath /home/packages --configfile $XDG_DATA_HOME/NuGet.Config

Note

NuGet 3.4 以降では、repositoryPath=%PACKAGEHOME% (Windows) および repositoryPath=$PACKAGEHOME (Mac/Linux) のように、すべての値で環境変数を使うことができます。

値の削除

値を削除するには、値を空にしてキーを指定します。

# Windows
nuget config -set repositoryPath= -configfile c:\my.Config

# Mac/Linux
nuget config -set repositoryPath= -configfile /home/my.Config

新しい構成ファイルの作成

.NET CLI を使用して、dotnet new nugetconfig を実行して既定の nuget.config を作成します。 詳細については、「dotnet CLI コマンド」を参照してください。

または、次のテンプレートを新しいファイルに手動でコピーした後、nuget config -configFile <filename> を使って値を設定します。

<?xml version="1.0" encoding="utf-8"?>
<configuration>
</configuration>

設定の適用方法

複数の NuGet.Config ファイルを使って設定を異なる場所に格納することで、1 つのソリューションや、ソリューションのグループに設定を適用できます。 これらの設定は、コマンド ラインまたは Visual Studio から呼び出されるすべての NuGet 操作に集合的に適用され、ソリューションまたは現在のフォルダーの "最も近く" に存在する設定が優先されます。 コマンド ライン ツールがソリューション ファイルではなくプロジェクト ファイルで使用されている場合、プロジェクト ディレクトリは "ソリューション ディレクトリ" として使用されています。この場合にソリューション ファイルのサブディレクトリに NuGet.Config ファイルがあると、動作の一貫性が保てない可能性があります。

具体的には、コマンド ラインで構成ファイルが明示的に指定されていない場合、NuGet はさまざまな構成ファイルから、次の順序で設定を読み込みます。

  1. (非一般的) NuGetDefaults.Config ファイル。パッケージ ソースのみに関連する設定が含まれます。
  2. コンピューター レベルのファイル。
  3. ユーザー レベルのファイル。
  4. ドライブ ルートから現在のフォルダー (nuget.exe が呼び出されたフォルダー、または Visual Studio のソリューションを含むフォルダー) までの間のパスに存在するすべてのフォルダーで見つかったファイル。 たとえば、コマンドが c:\A\B\C で呼び出された場合、NuGet により c:\、c:\A、c:\A\B、c:\A\B\C の順序で構成ファイルが検索されて読み込まれます。

設定ファイルがコマンド ラインで明示的に指定されている場合 (nuget -configFile my.config や dotnet restore --configfile my.config など)、指定したファイルの設定のみが使用されます。

NuGet はこれらのファイルで設定を探すので、適用は次のようになります。

  1. 単一項目の要素の場合は、前に検出された同じキーの値が置き換えられます。 つまり、現在のフォルダーまたはソリューションに "最も近い" 設定が、それより前に見つかった他の値をオーバーライドします。 たとえば、NuGetDefaults.Config の設定 defaultPushSource は、他の構成ファイルにも存在する場合はオーバーライドされます。
  2. コレクション要素の場合は (<packageSources> など)、すべての構成ファイルの値が 1 つのコレクションに結合されます。
  3. 指定されたノードに <clear /> が存在すると、そのノードより前に定義された構成値は無視されます。

ヒント

プロジェクト リポジトリの下に nuget.config ファイルを追加します。 これにより再現性が高まり、異なるユーザーの NuGet 構成が同一になるため、ベスト プラクティスと考えられています。

設定のチュートリアル

2 つの異なるドライブに次のフォルダー構造があるものとします。

disk_drive_1
    User
disk_drive_2
    Project1
        Source
    Project2
        Source
    tmp

その場合、次の場所にそれぞれ指定された内容の NuGet.Config ファイルが 4 つ存在します (コンピューター レベルのファイルはこの例には含まれませんが、ユーザー レベルのファイルと同じように動作します)。

ファイル A. ユーザーレベルのファイル (Windows では %appdata%\NuGet\NuGet.Config、Mac/Linux では ~/.config/NuGet/NuGet.Config):

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="nuget" value="https://api.nuget.org/v3/index.json" />
  </packageSources>
</configuration>

ファイル B。disk_drive_2/NuGet.Config:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <config>
        <add key="repositoryPath" value="disk_drive_2/tmp" />
    </config>
    <packageRestore>
        <add key="enabled" value="True" />
    </packageRestore>
</configuration>

ファイル C。disk_drive_2/Project1/NuGet.Config:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <config>
        <add key="repositoryPath" value="External/Packages" />
        <add key="defaultPushSource" value="https://MyPrivateRepo/ES/api/v2/package" />
    </config>
    <packageSources>
        <clear /> <!-- ensure only the sources defined below are used -->
        <add key="MyPrivateRepo - ES" value="https://MyPrivateRepo/ES/nuget" />
    </packageSources>
</configuration>

ファイル D。disk_drive_2/Project2/NuGet.Config:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <packageSources>
        <!-- Add this repository to the list of available repositories -->
        <add key="MyPrivateRepo - DQ" value="https://MyPrivateRepo/DQ/nuget" />
    </packageSources>
</configuration>

NuGet は、呼び出された場所に応じて、次のように設定を読み込んで適用します。

  • disk_drive_1/users から呼び出した場合: ユーザー レベルの構成ファイル (A) でリストされている既定のリポジトリのみが使われます。それが disk_drive_1 で見つかる唯一のファイルであるためです。

  • disk_drive_2/ または disk_drive_/tmp から呼び出した場合: NuGet は、最初にユーザー レベルのファイル (A) を読み込んだ後、disk_drive_2 のルートに移動して、ファイル (B) を見つけます。 NuGet は /tmp でも構成ファイルを検索しますが、見つかりません。 その結果、nuget.org の既定のリポジトリが使われ、パッケージの復元が有効になり、パッケージが disk_drive_2/tmp に展開されます。

  • disk_drive_2/Project1 または disk_drive_2/Project1/Source から呼び出した場合: NuGet は、最初にユーザー レベルのファイル (A) を読み込み、次に disk_drive_2 のルートからファイル (B) を読み込み、最後にファイル (C) を読み込みます。 (C) の設定で (B) および (A) の設定がオーバーライドされるので、パッケージがインストールされる repositoryPath は、disk_drive_2/tmp ではなく disk_drive_2/Project1/External/Packages です。 また、(C) は <packageSources> をクリアするので、ソースは https://MyPrivateRepo/ES/nuget だけになり、nuget.org は使うことができなくなります。

  • disk_drive_2/Project2 または disk_drive_2/Project2/Source から呼び出した場合: ユーザー レベルのファイル (A)、ファイル (B)、ファイル (D) の順に読み込まれます。 packageSources はクリアされないので、nuget.org と https://MyPrivateRepo/DQ/nuget の両方をソースとして使うことができます。 パッケージは、(B) で指定されている disk_drive_2/tmp に展開されます。

追加のユーザー全体の構成

5.7 以降、NuGet には追加のユーザー全体の構成ファイルのサポートが追加されました。 これにより、サードパーティー ベンダーは昇格せずにユーザー構成ファイルを追加できます。 これらの構成ファイルは、config サブフォルダー内の標準のユーザー全体の構成フォルダー内にあります。 .config または .Config で終わるすべてのファイルが考慮されます。 標準のツールでこれらのファイルを編集することはできません。

OS プラットフォーム 追加の構成
Windows %appdata%\NuGet\config\*.Config
Mac/Linux ~/.config/NuGet/config/*.config または ~/.nuget/config/*.config

NuGet の既定のファイル

NuGetDefaults.Configは一般的ではなく、パッケージのインストール元および更新元であるパッケージ ソースを指定するか、nuget push でパッケージを公開するときの既定のターゲットを制御することしかできません。

管理者は開発用およびビルド用のコンピューターに整合性のある NuGetDefaults.Config ファイルを容易に (たとえば、グループ ポリシーを使って) 展開できるので、nuget.org を含むかどうかに関わらず、組織内のすべてのユーザーが一貫したパッケージ ソースを使うようにすることができます。

重要

NuGetDefaults.Config ファイルにより、パッケージ ソースが開発者の NuGet 構成から削除されることはありません。 つまり、開発者が既に NuGet を使っていて、したがって nuget.org パッケージ ソースが登録されている場合、NuGetDefaults.Config ファイルの作成後に nuget.org は削除されません。

さらに、NuGetDefaults.Config や NuGet のその他のメカニズムが nuget.org などのパッケージ ソースへのアクセスを防ぐことはありません。このようなアクセスをブロックする場合は、ファイアウォールなどの他の手段をとる必要があります。

NuGetDefaults.Config の場所

次の表は、ターゲットの OS に応じた NuGetDefaults.Config ファイルの格納場所の一覧です。

OS プラットフォーム NuGetDefaults.Config 場所
Windows Visual Studio 2017 または NuGet 4.x+: %ProgramFiles(x86)%\NuGet
Visual Studio 2015 以前または NuGet 3.x 以前: %PROGRAMDATA%\NuGet
Mac/Linux $XDG_DATA_HOME (通常は ~/.local/share または /usr/local/share。OS のディストリビューションに依存します)

NuGetDefaults.Config の設定

  • packageSources: このコレクションは標準の構成ファイルの packageSources と同じ意味であり、既定のソースを指定します。 NuGet は、packages.config 管理形式を使用してプロジェクトのパッケージをインストールまたは更新するときに、ソースを順番に使用します。 PackageReference 形式を使用するプロジェクトの場合、構成ファイルの順序に関係なく、NuGet はまずローカル ソースを使用し、次にネットワーク共有のソースを使用し、次に HTTP ソースを使用します。 復元操作の場合、NuGet はソースの順序を常に無視します。

  • disabledPackageSources: このコレクションも NuGet.Config ファイルと同じ意味であり、影響を受ける各ソースの名前と、ソースが無効かどうかを示す true/false の値を列記します。 これにより、ソースの名前と URL を、既定で有効にしなくても、packageSources に残しておくことができます。 個々の開発者は、正しい URL を改めて調べなくても、他の NuGet.Config ファイルでソースの値を false に設定することにより、ソースを再び有効にできます。 これは、組織の内部ソースの URL の完全なリストを開発者に提供しながら、既定で個別のチームのソースのみを有効にする場合にも便利です。

  • defaultPushSource: nuget push 操作の既定のターゲットを指定し、nuget.org の組み込みの既定値をオーバーライドします。 管理者がこの設定を展開すると、開発者は nuget.org に公開するには nuget push -Source を明示的に使う必要があるため、内部パッケージがパブリックの nuget.org に誤って公開されるのを防ぐことができます。

NuGetDefaults.Config とアプリケーションの例

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <!-- defaultPushSource key works like the 'defaultPushSource' key of NuGet.Config files. -->
    <!-- This can be used by administrators to prevent accidental publishing of packages to nuget.org. -->
    <config>
        <add key="defaultPushSource" value="https://contoso.com/packages/" />
    </config>

    <!-- Default Package Sources; works like the 'packageSources' section of NuGet.Config files. -->
    <!-- This collection cannot be deleted or modified but can be disabled/enabled by users. -->
    <packageSources>
        <add key="Contoso Package Source" value="https://contoso.com/packages/" />
        <add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
    </packageSources>

    <!-- Default Package Sources that are disabled by default. -->
    <!-- Works like the 'disabledPackageSources' section of NuGet.Config files. -->
    <!-- Sources cannot be modified or deleted either but can be enabled/disabled by users. -->
    <disabledPackageSources>
        <add key="nuget.org" value="true" />
    </disabledPackageSources>
</configuration>