現在、2つのMVCWebアプリケーションが完全に独立して実行されています。目的は、これら2つのサイトを、共有認証などのある種のイントラネットと、それぞれにリンクしているある種のホームページで結び付けることです。
これまでに、3番目のMVCアプリケーションを作成し、既存の両方のサイトをMVC領域として追加しました。これは、うまく機能します。また、単一のソリューションの下で、各領域を独自のVisualStudioプロジェクトに分割することもできました。
2つの領域はそれぞれ、ビジネスの完全に異なる部門によって仕様が定められており、（通常は）異なる開発者によって開発されており、独立したリリースサイクルに従う必要があります。
現在のアプローチは、各エリアを別々のリポジトリパスに配置し、ビルドサーバーに各エリアの適切なブランチをチェックアウトさせ、メインWebアプリケーション（イントラネットホームページのもの）をビルドして、参照エリアプロジェクトをビルドすることです。これに伴う問題は、1つの領域だけがリリースを必要としている場合でも、常に3つのプロジェクトすべてを毎回デプロイする必要があることです。
これは大規模な取引ではありません（メインのイントラネットWebアプリの新しい未テストのリリースをエリアと一緒に誤ってデプロイしないと仮定します）が、ビルドサーバーが特定のビルドのすべてのアセンブリに同じスタンプを付けることも意味しますバージョンナンバー。
2番目のアプローチは、メインのイントラネットプロジェクトが、プロジェクト自体ではなく、エリアプロジェクトのアセンブリのみを参照することでした。そのため、各エリアを再度構築したり、その逆を行ったりすることなく、独自に構築できました。これに関する2つの問題、MS WebDeploy（ビルドサーバーがコードを公開するために使用）を使用して特定のアセンブリのみを公開する方法がわかりません。次に、ビューが動的に適切にコンパイルされないため、アセンブリ参照だけでなく、プロジェクト参照として個別のアセンブリのMVC領域を追加する必要があるようです（〜/ Views / web.configがありませんか？）
これに対するより良いアプローチはありますか？
編集：プロジェクト参照ではなく、領域への通常のアセンブリ参照を使用してメインWebアプリケーションを実行することができました（完全にはわかりませんが、機能するだけです）。これは、必要に応じてメインアプリとは独立してエリアを構築できることを意味します。
次の問題は、MSDeployを使用してロット全体を展開することです。エリアアセンブリは、メインアプリとともに/ binディレクトリにデプロイされますが、エリアのビュー/スクリプト/コンテンツは含まれません。ビューをアセンブリ自体にコンパイルするためのさまざまな手法を検討していますが、これをまだ機能させることができないようです。