動的にコンパイルされたアセンブリをアンロードする（メモリを再利用する）唯一の方法がアプリドメインをアンロードすることであるとすると、SharePointは、この制限にぶつかることなく、特にマスターページとページレイアウトについて、VirtualPathProvidersにどのように依存しますか？
マスターページとページレイアウトが頻繁に更新および公開される場合、再起動はさまざまな設定によって遅延する可能性がありますが、完全に回避することはできません。
（これに関する情報の欠如は、公開パターンでは一般的ではない、より理論的な制限に起因しますか？アプリの不安定性を引き起こすマスターページまたはレイアウトへの変更の割合に個人的に気づきましたか？SharePointに警告を表示する必要がありますか？）
動的Webフォーム（デフォルトではMVCビューを含む）を活用するCMS風の機能は、変化率の不安定性の影響を受けやすいですよね？
コンパイルされていないページの更新：
コンパイルなしのページASP.NET2.0では、コンパイルモデルが大幅にリファクタリングされ、拡張されています。サイトの事前コンパイルは、おそらく最も人気があり、新機能の中で大声で要求されています。もう1つの非常に興味深い機能は、ページをコンパイルしないことです。それらは決してコンパイルされない特別なページです。では、コンパイルなしのページの最終的な目的は何ですか？また、静的HTMLページとの違いは何ですか？まず、@ PageディレクティブのCompilationMode属性をNeverに設定して、コンパイルなしのページを作成します。コンパイルなしのページが要求された場合、ページアセンブリは作成されず、ディスクに保持されません。代わりに、ページビルダーコンポーネントのインスタンスがメモリにキャッシュされ、すべてのリクエストのページ出力を作成するために使用されます。ページビルダーは、ページコントロールツリーを構築する際にページパーサーをサポートする特別なコンポーネントです。コンパイルがオンになっている場合、コンパイルするクラスを取得するためにコントロールツリーが使用されます。コンパイルがオフの場合、コントロールツリーを使用してマークアップを取得します。言うまでもなく、プログラマーに独自のコードをページに添付する力を与えたい場合は、クラスが必要です。ノーコンパイルページはサーバーコントロールとリテラルで構成されていますが、コードはまったく含まれていません。
コンパイルなしのページは、すべてのアプリケーションに対応しているわけではありません。これらは、数千ページの非常に大規模なWebサイトのスケーラビリティを向上させるためにのみ設計されています。コンパイルなしのページをコードファイルにバインドしたり、サーバー側のブロックを含めることはできません。コンパイルなしのページで許可される実行可能なコードは、$式のみです。コンパイルしないページには2つの主な利点があります。SharePointのような安全な環境では、コンパイルなしのページにより、開発者は、ホスティング環境に問題を引き起こしたり、さらには破壊したりする可能性のあるバグのあるコードを記述できなくなります。大規模なコンテンツベースのWebサイトでは、コンパイルしないページを使用すると、何千ものページをコンパイルする必要がなくなります。
参照：
1 – http://haacked.com/archive/2009/04/22/scripted-db-views.aspx
