0

複数のプロジェクトを含むソリューションがあるので、たとえば、10個のテスト関連プロジェクトがnunitに依存しているとします。現在、私のソリューション構造にはToolsとLibのフォルダーが含まれているため、nunitの完全なダウンロードはToolsにあり、dllだけがLibにある可能性があります。

パッケージマネージャー（私が見ているのはNuGetとOpenWrapの2つです）は、パッケージの独自の「既知の」場所を作成する必要があると思います。したがって、パッケージ管理の昔ながらの方法に対して、Libフォルダーを手動で更新した後、nunitに依存しているすべてのプロジェクトが更新されたことがわかります。

しかし、パッケージマネージャーで更新する場合は、すべてのプロジェクトにアクセスして、プロジェクトが更新され、同じ参照を指していることを確認する必要があります。また、一部のdllが見つからない可能性があるため（現在unHAddinsを考えています）、手動のパッケージ管理から完全に解放されていません。つまり、最新の更新への移行は、すべてのプロジェクトがパッケージマネージャーによって更新されるまで行われません。

ですから、私の理解が正しいかどうか疑問に思っています。適切なサイズのソリューションにパッケージ管理を組み込むための最良のアプローチは何ですか。たとえば、次のようになります。 

0) add to source control: NuGet 'packages' folder or OpenWrap 'wraps' folder  
1) pick a dll (start with one that you beleieve has minimal dependencies)  
2) pick a project (ideally with minimal dependencies that might break)  
3) if OpenWrap, get the package you want into 'wraps'
4) for each project:  
    a) add reference to subject dll (manually if OpenWrap, NuGet will add for you)  
    b) fix compile error as needed  
    c) run tests

それは正しいですか？

乾杯、
ベリール

4

1 に答える 1

1

質問に答えるために、openwrapで何もする必要はありません。すべてのプロジェクトがスコープ内のすべての依存関係をインポートするため、更新はすべてに適用されます。

他のパッケージマネージャーについては答えられませんが、openwrapでは、追加または更新したときにプルされたパッケージを使用して、ソース管理に/wrapsフォルダーを追加します。このプロセスでは、最初にリモートリポジトリからパッケージを追加し（または、使用可能なアセンブリがない場合は既存のアセンブリからパッケージを作成し）、/libから手動で参照を削除します。OpenWrapでは、csprojへの参照を追加せず、ビルド時に追加するため、/ libにすでに依存関係がある場合は、追加しません。つまり、すべてのパッケージを追加し、参照を次々に削除して、毎回テストを実行できます。

うまくいけば、これはすべてのdllがパッケージとして利用可能になるまでの一時的な問題であり、かなり迅速に発生します。

于 2011-02-15T16:35:53.297 に答える