複数のソリューションで参照されているプロジェクトを含む外部および内部のパッケージソースで同様の状況があります。今日、コードベースの1つでこれを動作させたところ、開発者のワークステーションとビルドサーバーで動作しているようです。以下のプロセスでは、このシナリオを念頭に置いています（ただし、他の場所に共通パッケージフォルダーを配置するように適応させるのは難しくありません）。
- コードベース
- プロジェクトA
- プロジェクトB
- プロジェクトC
- ソリューション
- 解決策1
- 解決策2
- 解決策3
- パッケージ（これはすべてのソリューションで共有される一般的なパッケージです）
Visual Studio 2015 Update 3でNuGet 3.5.0.1484以降の回答を更新
このプロセスは、私が最初にこれに取り組み、これを更新するときだと思ったときよりも少し簡単になりました。一般に、プロセスは同じですが、手順が少なくなります。結果は、以下を解決または提供するプロセスです。
- ソースコード管理にコミットする必要のあるすべてのものが表示され、ソリューションで追跡されます
- Visual Studioのパッケージマネージャーを使用して新しいパッケージをインストールまたはパッケージを更新すると、正しいリポジトリパスが使用されます
- 初期構成後、.csprojファイルのハッキングはありません
- 開発者用ワークステーションの変更なし（コードはチェックアウト時にビルドできる状態です）
知っておくべきいくつかの潜在的な欠点があります（YMMVにはまだ経験していません）。ベノールを参照してください以下の回答とコメントを。
NuGet.Configを追加する
\ Solutions \フォルダーのルートにNuGet.Configファイルを作成します。これが作成するUTF-8エンコードファイルであることを確認します。これを行う方法がわからない場合は、Visual Studioの[ファイル]-> [新規]-> [ファイル]メニューを使用して、XMLファイルテンプレートを選択してください。以下をNuGet.Configに追加します。
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<config>
<add key="repositoryPath" value="$\..\Packages" />
</config>
</configuration>
repositoryPath設定では、$トークンを使用して絶対パスまたは相対パス（推奨）を指定できます。$トークンは、NuGet.Configが配置されている場所に基づいています（$トークンは、実際には1つ下のレベルを基準にしています。にはNuGet.Configの場所のの）。したがって、\ Solutions \ NuGet.Configがあり、\ Solutions \ Packagesが必要な場合は、値として$ \ .. \ Packagesを指定する必要があります。
次に、「NuGet」のようなソリューションにソリューションフォルダーを追加します（ソリューションを右クリックして、[追加]、[新しいソリューションフォルダー]の順にクリックします）。ソリューションフォルダーは、Visual Studioソリューションにのみ存在する仮想フォルダーであり、ドライブ上に実際のフォルダーを作成しません（どこからでもファイルを参照できます）。"NuGet"ソリューションフォルダーを右クリックし、[追加]、[既存のアイテム]の順にクリックして、\ Solutions \ NuGet.Configを選択します。
これを行う理由は、それがソリューションに表示され、ソースコード管理に適切にコミットされていることを確認するのに役立つためです。共有プロジェクトに参加しているコードベースのソリューションごとに、この手順を実行することができます。
NuGet.Configファイルを.slnファイルの上にある\ Solutions \に配置することにより、NuGetがフォルダー構造を「現在の作業ディレクトリ」から上方向に再帰的に移動して、使用するNuGet.Configファイルを探します。「現在の作業ディレクトリ」とは、ここでは2つの異なることを意味します。1つはNuGet.exeの実行パスで、もう1つは.slnファイルの場所です。
パッケージフォルダを切り替える
まず、各ソリューションフォルダーを確認し、存在する\ Packages \フォルダーを削除することを強くお勧めします（最初にVisual Studioを閉じる必要があります）。これにより、NuGetが新しく構成された\ Packages \フォルダーを配置している場所を簡単に確認できるようになり、間違った\ Packages \フォルダーへのリンクが失敗し、修正できるようになります。
Visual Studioでソリューションを開き、Rebuild Allを開始します。表示されるすべてのビルドエラーを無視します。これは現時点で予想されることです。ただし、これにより、ビルドプロセスの開始時にNuGetパッケージの復元機能が開始されます。\ Solutions \ Packages \フォルダーが目的の場所に作成されていることを確認します。表示されていない場合は、構成を確認してください。
ここで、ソリューションの各プロジェクトについて、次のことを行います。
- プロジェクトを右クリックし、[プロジェクトのアンロード]を選択します
- プロジェクトを右クリックし、[your-xxx.csprojの編集]を選択します。
- \ packages \への参照を見つけて、新しい場所に更新します。
- これらのほとんどは<HintPath>参照ですが、すべてではありません。たとえば、WebGreaseとMicrosoft.Bcl.Buildには、更新が必要な個別のパス設定があります。
- .csprojを保存し、プロジェクトを右クリックして、[プロジェクトの再読み込み]を選択します。
すべての.csprojファイルが更新されたら、別の[すべて再構築]を開始すると、参照の欠落に関するビルドエラーが発生しなくなります。これで完了です。共有パッケージフォルダーを使用するようにNuGetが構成されました。
NuStudio 2.7.1（2.7.40906.75）とVStudio 2012
まず覚えておくべきことは、nuget.configはnugetパッケージシステムのすべてのパス設定を制御するわけではないということです。これは理解するのに特に混乱しました。具体的には、msbuildとVisual Studio（msbuildを呼び出す）がnuget.configのパスを使用せず、nuget.targetsファイルでパスを上書きしていることが問題です。
環境の準備
まず、ソリューションのフォルダーを調べ、存在するすべての\ packages \フォルダーを削除します。これは、すべてのパッケージが正しいフォルダーに目に見える形でインストールされていることを確認し、ソリューション全体で不正なパス参照を発見するのに役立ちます。次に、最新のnuget Visual Studio拡張機能がインストールされていることを確認します。また、各ソリューションに最新のnuget.exeがインストールされていることも確認します。コマンドプロンプトを開き、各$（SolutionDir）\ .nuget \フォルダーに移動して、次のコマンドを実行します。
nuget update -self
NuGetの共通パッケージフォルダーパスの設定
各$（SolutionDir）\ .nuget \ NuGet.Configを開き、<configuration>セクション内に以下を追加します。
<config>
<add key="repositorypath" value="$\..\..\..\Packages" />
</config>
注：絶対パスまたは相対パスを使用できます。$を含む相対パスを使用している場合は、NuGet.Configの場所の 1つ下のレベルに相対的であることに注意してください（これはバグであると考えてください）。
MSBuildとVisual Studioの共通パッケージフォルダーパスの設定
各$（SolutionDir）\ .nuget \ NuGet.targetsを開き、次のセクションを変更します（Windows以外の場合は、その下に別のセクションがあることに注意してください）。
<PropertyGroup Condition=" '$(OS)' == 'Windows_NT'">
<!-- Windows specific commands -->
<NuGetToolsPath>$([System.IO.Path]::Combine($(SolutionDir), ".nuget"))</NuGetToolsPath>
<PackagesConfig>$([System.IO.Path]::Combine($(ProjectDir), "packages.config"))</PackagesConfig>
<PackagesDir>$([System.IO.Path]::Combine($(SolutionDir), "packages"))</PackagesDir>
</PropertyGroup>
PackagesDirを更新して
<PackagesDir>$([System.IO.Path]::GetFullPath("$(SolutionDir)\..\Packages"))</PackagesDir>
注： GetFullPathは、相対パスを絶対パスに解決します。
すべてのnugetパッケージを共通フォルダーに復元する
コマンドプロンプトを開き、各$（SolutionDir）\ .nugetに移動して、次のコマンドを実行します。
nuget restore ..\YourSolution.sln
この時点で、共通の場所に\ packages \フォルダーが1つあり、ソリューションフォルダー内にはありません。そうでない場合は、パスを確認してください。
プロジェクト参照の修正
すべての.csprojファイルをテキストエディターで開き、\ packagesへの参照を見つけて、正しいパスに更新します。これらのほとんどは<HintPath>参照ですが、すべてではありません。たとえば、WebGreaseとMicrosoft.Bcl.Buildには、更新が必要な個別のパス設定があります。
ソリューションを構築する
Visual Studioでソリューションを開き、ビルドを開始します。復元する必要のある不足しているパッケージについて不平を言っている場合は、パッケージが不足していて復元する必要があると思い込まないでください（エラーは誤解を招く可能性があります）。.csprojファイルの1つでパスが正しくない可能性があります。パッケージを復元する前に、まずそれを確認してください。
不足しているパッケージに関するビルドエラーがありますか？
.csprojファイルのパスが正しいことをすでに確認している場合は、2つの方法を試すことができます。これがソースコード管理からコードを更新した結果である場合は、クリーンコピーをチェックアウトしてからビルドしてみてください。これは私たちの開発者の1人にとってはうまくいき、.suoファイルまたは類似のものにアーティファクトがあったと思います。もう1つのオプションは、問題のソリューションの.nugetフォルダーにあるコマンドラインを使用して、パッケージの復元を手動で強制することです。
nuget restore ..\YourSolution.sln
$、相対パスの前にが欠けていたというものだと思います。また、NuGet.Configファイルに関する質問への回答はこちらです。それ.nugetの最初のルックス、そして、すべての親ディレクトリに、そしてあなたのAppDataで「グローバル」ファイルに：その後、（どんな逆の順序でそれらを適用している手段）。