24

更新:
これは私の最も多く寄せられる質問の 1 つですが、それでも自分のプロジェクトにとって満足のいく解決策はまだ見つかっていません。別の質問への回答で読んだ 1 つのアイデアは、リストから選択したプロジェクトのソリューションを「その場で」構築できるツールを作成することです。私はまだそれを試していません。

非常に大規模なアプリケーションをどのように構築しますか?

  • 複数の小さなプロジェクト/アセンブリを 1 つの大きなソリューションにまとめていますか?
  • いくつかの大きなプロジェクト？
  • プロジェクトごとに 1 つのソリューションですか?

また、ソリューションが 1 つもない場合、依存関係をどのように管理しますか。注: Google で見つけた回答ではなく、経験に基づいたアドバイスを求めています (自分でできることです)。

私は現在、80 以上の dll を持つアプリケーションに取り組んでおり、それぞれが独自のソリューションになっています。依存関係の管理はほぼフルタイムの仕事です。依存関係の dll をあちこちにコピーするための機能が追加されたカスタムの社内 'ソース管理' があります。私には次善の解決策のように思えますが、より良い方法はありますか? 80 のプロジェクトでソリューションに取り組むことは、実際にはかなり大雑把になると思います。

(コンテキスト: Web ではなく、winforms)

編集：（これが別の質問だと思う場合は、コメントを残してください）

以下の間に相互依存関係があるように私には思えます。

  • アプリケーションのプロジェクト/ソリューション構造
  • フォルダ/ファイル構造
  • ソース管理の分岐構造 (分岐を使用する場合)

しかし、これらを分離して個別に検討することは非常に困難です。

ここで別の関連する質問をしました。

4

9 に答える 9

5

ソース管理

4 つまたは 5 つの個別のソリューションに組み込まれている 20 または 30 のプロジェクトがあります。Subversion for SCM を使用しています。

1) SVN には、名前空間とプロジェクト名によって論理的に編成されたすべてのプロジェクトを含む 1 つのツリーがあります。それらすべてをビルドするルートに .sln がありますが、これは必須ではありません。

2) 実際のソリューションごとに、必要なすべてのプロジェクトへの SVN:External 参照を持つ SVN に新しいトランク フォルダーがあり、メイン ツリーの下の場所から更新されます。

3) 各ソリューションには、.sln ファイルとその他のいくつかの必要なファイル、およびそのソリューションに固有でソリューション間で共有されないコードが含まれます。

小規模なプロジェクトを多数持つのは少し面倒な場合があります (たとえば、TortoiseSVN の更新メッセージがすべての外部リンクで乱雑になります) が、依存関係を循環させることができないという大きな利点があるため、UI プロジェクトは BO に依存しています。プロジェクトですが、BO プロジェクトは UI を参照できません (参照すべきではありません!)。

アーキテクチャMS SCSF および CAB エンタープライズパターン を使用するように完全に切り替えて、さまざまなプロジェクトを組み合わせ、Win フォーム インターフェイスでやり取りする方法を管理しています。あなたが同じ問題を抱えているかどうかはわかりませんが (複数のモジュールが共通のフォーム環境でスペースを共有する必要があります)、そうであれば、ソリューションを設計して組み立てる方法にある程度の正気と慣習がもたらされる可能性があります。

以前は厳格な 3 レベルのポリシーを維持していましたが、SCSF は BO と UI タイプの機能を同じモジュールにマージする傾向があるためです。

FW - フレームワーク コード。機能がソフトウェア関連に関連するコード。BO - ビジネス オブジェクト。問題領域に関係する機能を持つコード。UI - UI に関連するコード。

そのシナリオでは、依存関係は厳密に UI -> BO -> FW です。

SCSFで生成されたモジュールを使用している間でもその構造を維持できることがわかったので、すべてがうまくいっています:-)

于 2008-09-30T08:07:45.250 に答える
2

依存関係を管理するには、アセンブリ/名前空間/プロジェクトの数に関係なく、ツールNDependを一目で確認できます。

個人的には、必要に応じて 1 つまたは複数のソリューション内で、大規模なプロジェクトをいくつか促進します。ここにそうする動機について書きました: C# および VB.NET コンパイラのパフォーマンスの恩恵を受ける

于 2008-10-27T18:12:25.987 に答える
1

私が取り組んできたいくつかのシステムでは、コンポーネントごとに異なるソリューションがありました。各ソリューションには、共通の出力フォルダー（DebugおよびReleaseサブフォルダーを含む）がありました。

ソリューション内でプロジェクト参照を使用し、それらの間でファイル参照を使用しました。各プロジェクトは、参照パスを使用して、他のソリューションからアセンブリを見つけました。VSがパスの検証を要求するため、.csproj.userファイルを手動で編集して、$（Configuration）msbuild変数を参照パスに追加する必要がありました。

VS以外のビルドの場合、プロジェクトの依存関係を再帰的に識別し、subversionからフェッチしてビルドする、msbuildスクリプトを作成しました。

于 2009-09-29T05:56:18.637 に答える
1

最善の解決策は、それをより小さな解決策に分割することだと思います。私が現在働いている会社でも、同じ問題があります。80 のプロジェクト ++ がソリューションに含まれています。私たちが行ったことは、プロジェクトが一緒に属するいくつかの小さなソリューションに分割することです。他のプロジェクトからの依存 dll がビルドされ、プロジェクトにリンクされ、プロジェクトと共にソース管理システムにチェックインされます。より多くのディスク容量を使用しますが、ディスクは安価です。このようにすることで、バージョン 1.5 へのアップグレードが絶対に必要になるまで、プロジェクトのバージョン 1 を使用できます。ただし、他のバージョンのdllにアップグレードすることを決定した場合でも、dllを追加する仕事があります。TreeFrogと呼ばれる Google コードのプロジェクトがあります。これは、ソリューションと開発ツリーを構造化する方法を示しています。まだマッシュドキュメンテーションは含まれていませんが、構造を見ればやり方がわかると思います。

于 2008-09-30T07:48:26.530 に答える
1

私がよく見た方法は、プロジェクト全体のビルドをテストできるようにするために、すべてのプロジェクトを含む1つの大きなソリューションを用意することです（大きすぎるため、実際にこれを使用してビルドすることはありませんでした）。さまざまな関連プロジェクトがグループ化された、開発者が使用する小さなプロジェクト。

これらには他のプロジェクトとの依存関係がありましたが、インターフェイスが変更されたり、使用していた dll のバージョンを更新する必要がない限り、他のすべてを心配することなく、小さなプロジェクトを引き続き使用できました。したがって、作業中にプロジェクトをチェックインし、(バージョン番号を変更した後に) 他のユーザーが使用を開始する必要があるときにそれらを固定することができます。

最後に、週に 1 ～ 2 回、またはそれ以上の頻度で、固定されたコードのみを使用してソリューション全体を再構築し、統合が正しく機能しているかどうかを確認し、テスターに​​テスト用の適切なビルドを提供しました。

コードの大部分は頻繁に変更されないことがよくあるため、常にロードしても意味がありません。(小規模なプロジェクトに取り組んでいる場合。)

このアプローチを使用するもう 1 つの利点は、一部の機能が完了するまでに数か月かかる場合があったことです。上記のアプローチを使用することで、他の作業の流れを中断することなく作業を続行できました。

これの重要な基準の 1 つは、ソリューション全体に多くの相互依存関係がないことだと思います。もしそうなら、このアプローチは適切ではないかもしれません。

于 2008-09-30T08:04:48.330 に答える
1

ほとんどの開発者がほとんどの場合他のソリューションを使用するとしても、80 個のプロジェクトすべてを含むソリューションを用意することは非常に重要だと思います。私の経験では、1 つの大きなソリューションで作業する傾向がありますが、F5 キーを押すたびにすべてのプロジェクトを再構築するという苦痛を避けるために、ソリューション エクスプローラーに移動し、現在関心のないプロジェクトを右クリックします。 「プロジェクトのアンロード」を行います。そうすれば、プロジェクトはソリューションにとどまりますが、費用はかかりません。

そうは言っても、80は大きな数です。これらの 80 が個別のサブシステムにどの程度うまく分解されるかに応じて、それぞれが意味のあるサブセットを含む他のソリューション ファイルも作成する可能性があります。これにより、多くの右クリック/アンロード操作の労力を節約できます。とはいえ、1 つの大きな解決策があるということは、それらの相互依存関係の決定的なビューが常に存在することを意味します。

私が使用したすべてのソース管理システムで、VS 統合は .sln ファイルをソース管理に配置することを選択し、その .sln ファイルがソース管理にない限り、多くは適切に機能しません。.sln ファイルはプロジェクト全体ではなく、個人的なものと見なされていたので、これは興味深いことです。ソース管理に確実に値する唯一の種類の .sln ファイルは、すべてのプロジェクトを含む「1 つの大きなソリューション」だと思います。たとえば、自動ビルドに使用できます。私が言ったように、個人は利便性のために独自のソリューションを作成する可能性があります。私はソース管理に反対するつもりはありませんが、プロジェクトよりも個人にとって意味のあるものです。

于 2008-09-30T07:26:04.197 に答える
1

次の理由で、プロジェクトの参照を断念しました (マクロは素晴らしいように聞こえますが)。

  • 依存プロジェクトが存在する場合と存在しない場合がある異なるソリューション間を切り替えるのは簡単ではありませんでした。
  • プロジェクトを単独で開いてビルドし、他のプロジェクトから独立してデプロイできるようにする必要がありました。プロジェクト参照を使用してビルドすると、プロジェクト参照によって特定のバージョン以上を検索するなどの理由で、展開に問題が発生することがありました。これにより、さまざまなバージョンの依存関係をスワップインおよびスワップアウトするミックス アンド マッチ機能が制限されました。
  • また、さまざまな .NET Framework バージョンを指すプロジェクトがあったため、実際のプロジェクト参照が常に行われるとは限りませんでした。

（参考までに、私が行ったことはすべてVB.NET用であるため、C＃の動作に微妙な違いがあるかどうかはわかりません）

だから、私：

  • C:\GlobalAssemblies などのグローバル フォルダーから、ソリューションで開いているプロジェクトとそうでないプロジェクトに対してビルドします。
  • 私の継続的インテグレーション サーバーは、これをネットワーク共有上で最新の状態に保ちます。新しいものをローカル フォルダーに同期するためのバッチ ファイルがあります。
  • C:\GlobalAssembliesDebug のような別のローカル フォルダーがあり、各プロジェクトには、DEBUG モードの場合にのみ、bin フォルダーの内容をこのデバッグ フォルダーにコピーするビルド後のステップがあります。
  • 各プロジェクトには、これら 2 つのグローバル フォルダーが参照パスに追加されています。(最初に C:\GlobalAssembliesDebug、次に C:\GlobalAssemblies)。この参照パスを .vbproj ファイルに手動で追加する必要があります。これは、Visual Studio の UI がそれらを .vbprojuser ファイルに追加するためです。
  • RELEASE モードの場合、C:\GlobalAssembliesDebug からコンテンツを削除するビルド前の手順があります。
  • ホスト プロジェクトである任意のプロジェクトで、コピーする必要がある dll 以外 (必要な他のプロジェクトの bin フォルダーに出力されたテキスト ファイル) がある場合、そのプロジェクトにビルド前の手順を実行してそれらをホスト プロジェクトにコピーします。
  • プロジェクトの依存関係を正しい順序でビルドするには、ソリューション プロパティでプロジェクトの依存関係を手動で指定する必要があります。

したがって、これが行うことは次のとおりです。

  • プロジェクト参照をいじることなく、あらゆるソリューションでプロジェクトを使用できます。
  • Visual Studio では、ソリューションで開いている依存関係プロジェクトにステップ インできます。
  • DEBUG モードでは、開いているロード済みプロジェクトに対してビルドします。したがって、最初に C:\GlobalAssembliesDebug を調べ、そこにない場合は C:\GlobalAssemblies を調べます。
  • RELEASE モードでは、C:\GlobalAssembliesDebug からすべてを削除するため、C:\GlobalAssemblies のみを検索します。これが必要な理由は、リリースされたビルドが、ソリューションで一時的に変更されたものに対してビルドされないようにするためです。
  • 労力をかけずにプロジェクトを簡単にロードおよびアンロードできます。

もちろん、完璧ではありません。デバッグ エクスペリエンスは、プロジェクト リファレンスほど優れていません。（「定義に移動」して正しく機能させることはできません）、およびその他のちょっとした風変わりなこと。

とにかく、それは私が物事を私たちにとって最善の方法で機能させようとしているところです.

于 2012-02-13T15:26:27.077 に答える
0

OK、この情報を消化し、プロジェクト参照に関するこの質問への回答も得たので、現在、この構成で作業しています。これは「私にとってはうまくいく」ようです:

  • アプリケーション プロジェクトとすべての依存関係アセンブリ プロジェクトを含む 1 つの大きなソリューション
  • いくつかの動的にインスタンス化されたアセンブリの手動依存関係 (プロジェクトを右クリック) を微調整して、すべてのプロジェクト参照を保持しました。
  • 3 つのソリューション フォルダー (_Working、Synchronized、および Xternal) があります。ソース管理が VS ( sob ) と統合されていないため、_Working と Synchronized の間でプロジェクトをすばやくドラッグ アンド ドロップできるので、見失うことはありません。変更の。XTernal フォルダーは、同僚に「属する」アセンブリ用です。
  • F5/F6 で再構築されるプロジェクトを制限できるように、'WorkingSetOnly' 構成 (Debug/Release ドロップダウンの最後のオプション) を作成しました。
  • ディスクに関する限り、私はすべてのプロジェクト フォルダーをいくつかのフォルダーの 1 つにまとめています (したがって、プロジェクトの上の 1 レベルの分類のみです)。
  • すべてのプロジェクト (dll、pdb & xml ) は同じ出力フォルダーにビルドされ、同じフォルダーが参照パスとして使用されます。(そして、すべての参照は [コピーしない] に設定されています) - これにより、ソリューションからプロジェクトを削除し、ファイル参照に簡単に切り替えることができます (そのためのマクロがあります)。
  • 「Projects」フォルダーと同じレベルに、「Solutions」フォルダーがあり、アセンブリに固有のテスト コード (たとえば) やドキュメント/デザインなどとともに、いくつかのアセンブリの個々のソリューションを管理しています。

現時点では、この構成はうまく機能しているように見えますが、大きなテストでは、それを同僚に売り込み、チームのセットアップとして機能するかどうかを確認します.

現在未解決の欠点:

  • すべての依存プロジェクトを常に含めたいとは限らないため、個々のアセンブリ ソリューションにはまだ問題があります。これにより、「マスター」ソリューションとの競合が発生します。壊れたプロジェクト参照をファイル参照に変換し、プロジェクトが追加された場合にファイル参照をプロジェクト参照に復元するマクロを (再び) 使用して、これを回避しました。
  • 残念ながら、ビルド構成をソリューション フォルダーにリンクする方法はありません (これまでに見つけた方法です)。「このフォルダー内のすべてをビルドする」と言うことができると便利です。現状では、これを手動で更新する必要があります (痛くて忘れやすい）。(ソリューション フォルダーを右クリックしてビルドできますが、F5 シナリオは処理されません)
  • ソリューション フォルダーの実装には (マイナーな) バグがあり、ソリューションを再度開くと、プロジェクトがアルファベット順ではなく、追加された順に表示されます。(私はMSでバグを開きました。明らかに修正されましたが、VS2010 の場合だと思います)
  • CodeRushXPressアドインをアンインストールする必要がありました。なぜなら、それはすべてのコードを詰まらせていたからです。しかし、これはビルド構成を変更する前だったので、もう一度試してみます。

まとめ - この質問をする前に私が知らなかった有用な情報:

  1. ソリューション フォルダーを使用して、ディスクをいじらずにソリューションを整理する
  2. 一部のプロジェクトを除外するためのビルド構成の作成
  3. ファイル参照を使用している場合でも、プロジェクト間の依存関係を手動で定義できる

これは私の最もよくある質問なので、この回答が読者の役に立てば幸いです。私はまだ他のユーザーからのさらなるフィードバックに非常に興味があります.

于 2008-11-18T11:14:02.863 に答える
0

メイン ブランチのソース管理に 1 つの巨大なソリューションがあります。

ただし、プロジェクトの小さな部分に取り組んでいるすべての開発者/チームには、必要なプロジェクトがわずかしかない 1 つのソリューションを含む独自のブランチがあります。そのようにして、そのソリューションは簡単に保守できるほど小さく、より大きなソリューションの他のプロジェクト/dll に影響を与えません。

ただし、これには 1 つの条件があります。ソリューション内に相互接続されたプロジェクトが多すぎてはなりません。

于 2008-09-30T08:43:42.637 に答える