foo.sln と bar.sln の 2 つのソリューションがあります。
foo と bar の両方で使用される共通のライブラリがあります。Common.csproj は両方で使用されます。
foo を開いて nuget 参照を更新すると、Common.csproj 内のすべての参照が foo/packages/ を指します。後でバーを開いて nuget 参照を更新すると、すべての参照が bar/packages/ 内の参照に設定されます。当然のことながら、これは Common.csproj と Foo.Data.csproj のような Foo 固有のものとの間に非互換性を引き起こす可能性があるため、foo チームを怒らせます。
「すべてのプロジェクトを含む巨大なソリューションを作成し、ナゲットに触れる必要がある場合は、そのソリューションからのみ行う」以外の明らかな解決策が必要です。
codeplex に問題があるようです(ちなみに、投票数が最も多い問題です) が、どうやらこの問題がどのように解決されるかを理解するには厚すぎます。誰かがこれを修正する方法を説明できますか?
この問題は NuGet に先行します。2 つのソリューションで参照されているプロジェクトがあり、一方のソリューションで開いているときにプロジェクトのアセンブリ参照を変更すると、当然ながら、もう一方のソリューションで開いているときにそのプロジェクトの参照パスが変更されます。これは、参照がどのように変更されたか (NuGet を使用するかどうか) に関係なく、常に当てはまります。
しかし、本当の問題は、更新を行ったときに、更新されたパッケージが foo/packages ディレクトリに表示されないことですよね?
簡単な解決策は、Common.csproj を独自のソリューションに移動し、独自の参照、パッケージ フォルダー、ビルドおよびリリース プロセスを使用することです。次に、関連する依存関係が組み込まれた独自の NuGet パッケージを作成します。次に、Common パッケージを Foo と Bar の両方にインストールできます。準備ができたら、Foo チームが Common の最新バージョンに自由に更新できます。
これに対して私が聞いた主な議論は、デバッグ中に共通コードをステップ実行したいかもしれないというものですが、これは Visual Studio 2010 ではもはや問題ではありません。
あなたが尋ねる必要がある基本的な質問は、Common.csproj の所有者は誰ですか? Foo チームですか、それとも Bar チームですか。
common.csproj を別のアセンブリとして参照し、ソリューションの依存関係ではなく独自の依存関係を持っていないのはなぜですか。
そうすることで、foo または bar のいずれかが参照されたパッケージを更新して壊すことから common を保護します。
私たちの場合、多くの開発者と tfs を使用したソリューション、およびさまざまなブランチにある複数のバージョンの開発者と、ソースがどこにある必要があるかについての各開発者の理解があります。
この場合の相対パスは機能しません。一致ディスクの場合の絶対パスは相対パスに置き換えられ、機能しませんでした。
私たちの解決策は、相対パスを取り除くことです。NuGetPackages を別のディスクに配置すると、それが可能になります。そのようです：
net use /persistent:yes p: \\localhost\C$\NuGetPackagesDiskFolder
任意のフォルダー名
その後、NuGet.Config で実際の絶対パスを指定できます
<config>
<add key="repositorypath" value="p:\NuGetPackages" />
</config>
<packageRestore>
<add key="enabled" value="True" />
</packageRestore>
結局 suo ファイルを削除
ps: 既存のソリューションがソース管理にある場合、既存のソリューションの変更に少し問題があります。最も簡単な方法は、各 .csproj で p:\NuGetPackages へのパスを修正することです。それ以外の場合は、すべての参照を再インストールし、すべての packages.config を手動で元に戻す必要があります。ソース管理で削除済みとしてマーク