Foo.slnとbar.slnの2つのソリューションがあります
Fooとbarの両方で使用される共通のライブラリがあります。 Common.csprojは両方で使用されます。
Fooを開いてnuget参照を更新すると、Common.csproj内のすべての参照がfoo/packages /を指します。後でbarを開いてnuget参照を更新すると、すべての参照がbar/packages /内の参照に設定されます。当然、これはfooチームを怒らせます。これは、Common.csprojとFoo.Data.csprojのようなFoo固有のものとの間に非互換性を引き起こす可能性があるためです。これは、依然としてfoo/packagesを指します。
「すべてのプロジェクトを含む巨大なソリューションを作成し、nugetに触れる必要がある場合は、そのソリューションからのみ実行する」以外の明白な解決策が必要です。
codeplexの問題 、(ちなみに、投票数の多い問題)があるようですが、明らかに私はこの問題がどのように解決されるかを理解するには厚すぎます。誰かがこれを修正する方法を説明できますか?
この問題はNuGetに先行します。 2つのソリューションで参照されているプロジェクトがあり、一方のソリューションで開いているときにプロジェクトのアセンブリ参照を変更する場合、もちろん、もう一方のソリューションで開いているときにそのプロジェクトの参照パスが変更されます。これは、参照がどのように変更されたか(NuGetなどを使用)に関係なく、常に当てはまります。
しかし、本当の問題は、更新を行うと、更新されたパッケージがfoo/packagesディレクトリに表示されないことです。
簡単な解決策は、Common.csprojを、独自の参照、パッケージフォルダー、ビルドおよびリリースプロセスを備えた独自のソリューションに移動することです。次に、関連する依存関係が組み込まれた独自のNuGetパッケージを作成します。次に、CommonパッケージをFooとBarの両方にインストールできます。その後、Fooチームは、準備ができたら、Commonの最新バージョンに自由に更新できます。
これに対して私が聞いた主な議論は、デバッグ中に共通コードをステップスルーしたいかもしれないということですが、これはVisual Studio2010ではもはや問題ではありません。
あなたが尋ねる必要がある基本的な質問は、Common.csprojを誰が所有しているのかということです。それはFooチームですか、それともBarチームですか?
$(SolutionDir)変数を含むようにプロジェクトファイルのヒントパスを変更することで問題を修正します。
Reference Include="EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL">
<HintPath>$(SolutionDir)packages\EntityFramework.6.1.3\lib\net40\EntityFramework.dll</HintPath>
私たちの場合、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を手動で元に戻す必要があります。ソース管理で削除済みとしてマーク
Common.csprojを、参照する別個のアセンブリとして持ち、その中のソリューションの依存関係ではなく、独自の依存関係を持っているのはなぜですか。
そうすることで、参照されているパッケージを更新して破壊するfooまたはbarからcommonを保護します。