大きなC＃ソリューションを整理する

Question

私はTFSで毎日構築される大きなソリューションを持っています。このソリューションは、複数の論理サブソリューションをカバーしています。たとえば、A、B、C、Dのプロジェクトで構成されるApplicationA、プロジェクトA、B、E、F、プロジェクトA、C、G、HからなるApplicationCからなるApplicationB。

現時点では、ビルドソリューションファイルのコピーをローカルに作成し、プロジェクトで作業するためにビルドする必要のないプロジェクトをアンロードします。したがって、ApplicationAではA、B、C、D以外のすべてをアンロードします。

もう1つのアプローチは、ApplicationAのプロジェクトA、B、C、Dのみをビルドする複数のソリューション構成を作成することですが、これは面倒で恐ろしく、.slnファイルは巨大になります。

問題は、多くのプロジェクトが1つのwixパッケージにまとめられ、一緒にインストールされることです。つまり、主な.slnファイルは意味があります。特に、ビルドの観点からですが、デバッグも重要です。

新しいプロジェクトが追加されたときに複数のソリューションファイルを追加する必要があります。だから、設定方法はおそらく行く方法ですが、どちらかといえば気分が悪いです。

誰もが同様のシナリオの経験を持っていますか？どのようにそれを回避しましたか？

Answer 1

それはそれは5つのソリューションファイルを持つことが理にかなってのように聞こえる：、

• Master.slnすべてのプロジェクト
• ApplicationA.slnが含まれ、プロジェクトA、B、C、D
• ApplicationBをが含まれていますslnファイルは、プロジェクトA、B、E、F
• ApplicaitonC.sln、プロジェクトA、C、G、H

が含まそれはカントーの全てを持っている罰金を含んseソリューションファイルを同じ最上位ディレクトリに保存します。

しかし、新しいプロジェクトが追加されたときに複数のソリューションに追加する必要があるので、複数のソリューションファイルを管理することは現実的ではありません。

なぜそれが問題ですか？とにかくプロジェクトが必要とされるアプリケーションを見つけ出す必要があります。マスターソリューションでプロジェクトを作成し、必要なソリューションには「既存のプロジェクトを追加」を使用します。それはです。実際にはではありません。新しいプロジェクトが頻繁に追加されるとは思わないでしょう。