通常のアセンブリでは、MEFを使用してアセンブリを動的に読み込むことができます。これらのアセンブリのライブ更新が必要な場合は、AppDomainsを使用して動的アセンブリをホストすることをお勧めします（潜在的にMAF（Managed Add-in Framework）を使用できます）。更新が必要な場合は、appdomainが停止し、アセンブリが更新され、appdomainがリロードされます。ASP .NETで動的にWebページをプラグインする方法（およびプラグインを更新する方法）
そのコードビハインドクラスを含むASP .NETによって読み込まれるアセンブリはどうですか？どのように私はメインのappdomainの再起動を強制することなくそれらを更新することができます。私のページのいくつかを動的なappdomainでホストすることは可能ですか？あなたはどうしますか？このappdomainはログイントークンと認証情報を共有できるので、ユーザーは再ログインする必要はありませんか？
おかげ
MEFは、AppDomainの分離をサポートしていないので、残念ながら、でも再構成時に、以前にロードされていたものをアセンブリはまだメインのWebアプリケーションのAppDomainにロードされます。そこには、ASP.NETで戦うために必要があるだろう二つのものです：
物理ファイルへの変更（例えば.aspxの、.cshtml、など）、またはコンフィギュレーションファイル（.configファイル）への変更は、または\ binディレクトリを変更すると、アプリケーションがリサイクルされます。これは、ページ/設定のファイル監視と\ binディレクトリのファイル監視という2つの理由によるものです（これは、デフォルトではASP.NETがファイルのシャドウコピーを使用するためです）。
MEFを別のAppDomainで使用するには、シリアライズまたはMarshalByRefのいずれかによって、ドメイン間通信が非常に必要になりますが、これはきれいな実装ではないと思います。 BuildProviderインスタンスを別のAppDomainでページを動的にコンパイルするために使用されるインスタンスをトリガーする方法が不明です。
これについてあまりにも多く考えているのでしょうか。 IIS6、HTTP.SYSは適切なWebサイトへの着信要求のルーティングを管理しているため、これはカーネルレベルで処理されます。メインアプリケーションが再起動したとしても（それにはさまざまな理由があります）、要求が破棄されることはありません。要求を渡す前に新しいワーカープロセスを待つだけです。確かに、ユーザーの観点からは、新しいアプリケーションの再起動を待っているアイドル時間に気付くかもしれませんが、現実的に、これらの変更をどれくらい頻繁に行うつもりですか？
多くのアプリケーション設計では、オーバーエンジニアリングが問題になります。すべてのシナリオに対して設計することができますが、シンプルで拡張可能なシステムを維持することは現実的に簡単です。私の意見では、あなたが指定したことをやりたければ、それはオーバーエンジニアリングとして分類されます。単純にする。
セッション "StateServer"を使用すると、アプリケーションプールのリサイクル（ファイルの更新による）間の認証が維持されます。あなたの実際の質問については
：
に作成されたときに、アセンブリの新しいバージョンは、優先すべき私はあなたの質問は、このメソッドは動作しませんと言っていると思いますか？あなたはどんなエラーを受けていますか...
あなたのお勧めは、単にプールをリサイクルしてから、新しいアセンブリをリロードすることです。あなたを正しく理解していますか？ – Mark
言い換えれば、はい。あなたには失望しているように見えるかもしれませんが、ASP.NETアプリケーションはこのように動作するように設計されています。アプリケーションのフィーチャセットを計画しているときは、設計している機能が最も一般的な使用例であるかどうかを検討する価値があります。それは理にかなっていますか？ –
私はサブアプリケーション（ネストされたWebアプリケーション）を作成して、親アプリケーションではなく子アプリケーションをリサイクルできるようにしました。あれについてどう思う？それはもう少し仕事かもしれませんが、それは私により柔軟性を与えるのですか？ – Mark