0

次のような構造で作成したライブラリがあります。

SolutionA\
--Source\
  --Core\
  --Tests\
--Tools\
  --TestFramework\
  --MockTool\
SolutionA.sln

これをのサブモジュールとして含めたいと思いSolutionBます。この構造全体をサブモジュールとして使用すると、SolutionB気にしないものがたくさん得られます。それは気にしませんSolutionA.sln; それは気にしませんTests\; 気にしませんTools\。本当に、SolutionB気にするのはCore\。

の別のリポジトリが必要なようですCore\。では、ソースが他のソリューションで使用されている.NETソリューション用に2つのリポジトリを用意するのが通常の習慣ですか？1つは（非テスト）コード自体（および必要なライブラリ）専用で、もう1つはテストツールとソリューションファイル用ですか？

4

2 に答える 2

1

ソリューションは、1つ以上のプロジェクトの単なるコンテナです。これは、同じ「ソリューション」フォルダまたは外部のどこかに分類される可能性があります。

プロジェクト（この場合は「コア」）がある場合は、1つ以上のソリューションからそのプロジェクトソースを直接参照できます。この場合、SolutionAとSolutionBです。

Tests \、TestFramework \、MockTool \などの無関係なものは、Coreで必要とされない限り、他のソリューションに含める必要はありません。

わかる？

于 2010-06-21T22:10:19.793 に答える
0

あなたはgit-submodulesでこれを解決することができます（あなたのタグはあなたがgitを使用していると私に信じさせます）。このようなものの「通常の習慣」が何であるかはわかりません。

サブモジュールの処理方法に関する私の質問への回答として、dirkは関連する問題を解決するためにnuget（.NET Frameworkのパッケージマネージャー。http：//nuget.orgを参照）を使用することを提案しました。dllの更新を制御し、必要に応じて依存関係を管理し、（少なくともクライアント側では）優れたツールサポートを利用できるため、適切なようです。

Scott Hanselmannが、nugetを継続的インテグレーションに統合する方法についての優れた記事を掲載しています。

于 2012-03-09T13:18:43.847 に答える