.Netで複数の重複するソリューション/プロジェクトを構成する方法は？

私は最近、複数の.netソリューションがあり、それぞれがそのソリューションに固有のいくつかのプロジェクトをホストしているが、他のプロジェクトを「借りる」/「リンクする」（既存のプロジェクトを追加する）古いレガシーコードベースを持つ新しいクライアントで働き始めました技術的には他のソリューションに属します（少なくともTFSのフォルダー構造を使用する場合）

これが絡み合ったセットアップを見たことはなく、明確なビルド順序はなく、ソリューションAのプロジェクトはソリューションBでホストされているプロジェクトの出力ディレクトリから直接DLLを参照する場合があり、プロジェクトが存在する場合でもプロジェクトが直接含まれている場合がありますフォルダー構造で遠ざかります。

すべてが開発者の怠lazのために最適化されているようです。

CIサーバーを持っていない理由について私が彼らに立ち向かったとき、彼らはそのように組織されたコードでセットアップするのは難しいと答えました。（私は今それを設定し、このコード編成を呪っている）

ソリューションは展開アーティファクト（一緒に展開する必要があるものは同じソリューション内にあります）を中心に編成されていますが、賢明な決定だと思いますが、それらのソリューション（プロジェクト）の内容はいたるところにあります。

複数のソリューション/展開アーティファクトで共通のクラスライブラリを再利用するときに使用するベストプラクティスのコンセンサスはありますか、

• VCSでコードを構造化する方法
• 個別のデプロイメントアーティファクト間でビジネスロジックの共有を促進する方法

私は、他のソリューションに属する既存のプロジェクトを含めることが好きではありませんでした。1つのソリューションに対してそのプロジェクトを編集すると、別のソリューションの何かが完全に壊れる変数が多すぎます。その後、その問題を修正することにより、元のソリューションを壊してしまいます。泡立て、すすぎ、繰り返します。

この種の依存関係が複数のソリューションに漏れる場合、依存コードをそのOWNソリューションに分離し、参照として含まれるブラックボックスライブラリを作成したいと思います。私の考えでは、デバッグはすべてのソリューションの共有プロジェクトに至るまで実行できるように、ソリューションが絡み合っていると考えています。ライブラリが適切に構築およびテストされている場合、この種のデバッグは実際には必要ありません。ライブラリは、それ自体のメリットに耐えることができ、すべての消費者プロジェクトの期待が一貫して満たされるように徹底的にテストされる必要があります。

あなたが言及しているようなTFS構造を実際に整理しましたが、CIには独自の課題がありますが、多くの異なる利点があります。1つの明確な理由は、適切なコンポーネント化を個別の.NETプロジェクトにサポートし、奨励することです。したがって、100％のテストカバレッジを促進することにより、優れたTDDをサポートします。すぐにあなたが対処できるいくつかの問題に気づきます。

ソリューションAのプロジェクトは、ソリューションBでホストされているプロジェクトの出力ディレクトリから直接DLLを参照する場合があります。フォルダー構造内にFARが離れていても、プロジェクトが直接含まれている場合があります。

他のディレクトリの出力へのバイナリ参照は良いアプローチではありません。また、プロジェクト参照と混ざり合うと悪いアプローチになります。少なくとも一貫性を保つため、バイナリ参照をプロジェクト参照に変更することをお勧めします。この時点で、各ソリューションは単一のビルド可能なアプリケーションまたはアプリケーション層を表すことができます（例：SuperApp.sln、OtherAppServices.sln、OtherAppPresentationTier.sln）。

すべてのプロジェクトをビルドするには、マスターソリューションも作成することをお勧めします。マスターソリューションには、すべてに対するプロジェクト参照があり、本質的には、アプリケーションスイートのすべてのプロジェクトを処理する単一のビルドコマンドを持つという唯一の利点のために存在します。開発者は、アクティブな開発またはデバッグにマスターソリューションを使用しないでください。これにより、ビルドアーティファクトの組み立てがはるかに簡単になります。

展開は、単純なバッチ、Powershell、またはPerlスクリプトを使用して実行できます。これにより、基本的に適切なソリューションまたはマスターソリューションが構築され、適切な環境にすべてが展開されます。正しく実行すれば、CIサーバーに簡単に統合できます。

•個別の展開アーティファクト間でビジネスロジックの共有を促進する方法

一般的なビジネスロジック用のプロジェクトを作成するか、よりグローバルまたはユニバーサルなビジネスロジックに対する懸念をより適切に分離します。これを参照したいすべての展開可能なソリューションは、プロジェクト参照によって参照する必要があります。

TFSでコードを整理する場合、共通または共有プロジェクトをディレクトリツリーの上位レベルに保持することで、これを簡単に実現できます。