通常のアセンブリの場合、MEF を使用してアセンブリを動的にロードできます。これらのアセンブリのライブ更新が必要な場合は、AppDomains を使用して動的アセンブリをホストすることをお勧めします (マネージド アドイン フレームワーク (MAF) を使用できる可能性があります)。更新が必要な場合、appdomain が停止され、アセンブリが更新され、appdomain が再読み込みされます。
コード ビハインド クラスを含む ASP .NET によって読み込まれるアセンブリについてはどうでしょうか。メインのアプリドメインを強制的に再起動せずに更新するにはどうすればよいですか? 一部のページを動的アプリケーション ドメインでホストすることはできますか? どうやってそれをしますか？ユーザーが再ログインする必要がないように、この appdomain でログイン トークンと認証情報を共有できますか?
ありがとう
MEF は AppDomain の分離をサポートしていないため、残念ながら、再構成中であっても、以前に読み込まれたアセンブリはメインの Web アプリケーション AppDomain に読み込まれたままです。ASP.NET で戦うために必要なことが 2 つあります。
物理ファイル (.aspx、.cshtml など) への変更、構成ファイル (.config) への変更、または \bin ディレクトリへの変更により、アプリケーションがリサイクルされます。これは、pages/configs のファイル監視と \bin ディレクトリのファイル監視の 2 つが原因です (これは、既定で ASP.NET がファイルのシャドウ コピーを使用するためです。これが推奨されます)。
別の AppDomain で MEF を使用するには、シリアライゼーションまたは .NET のいずれかを介して、非常に大量のクロスドメイン通信が必要にMarshalByRefなりますが、これはクリーンな実装ではないと思います。BuildProvider別の AppDomain でページを動的にコンパイルするために使用されるインスタンスをトリガーする方法もわかりません。
あなたはこれについて考えすぎているのではないかと思います。IIS6 以降、HTTP.SYS は着信要求の適切な Web サイトへのルーティングを管理しており、これはカーネル レベルで処理されます。メイン アプリケーションが再起動した場合でも (さまざまな理由が考えられます)、リクエストは削除されず、リクエストを渡す前に新しいワーカー プロセスを待機するだけです。確かに、ユーザーの観点からは、新しいアプリケーションが再起動するのを待っているアイドル時間に気付くかもしれませんが、現実的には、これらの変更をどのくらいの頻度で行うのでしょうか?
多くのアプリケーション設計は、オーバーエンジニアリングに悩まされています。すべてのシナリオに合わせて設計することもできますが、現実的には、シンプルで拡張可能なシステムを維持する方が簡単です。私の意見では、あなたが指定したことをしたいということは、オーバーエンジニアリングに分類されます。複雑にしないでおく。
セッション「StateServer」を使用すると、アプリ プールのリサイクル間で認証が保持されます (ファイルの更新が原因)。
実際の質問について：
あなたの質問は、この方法がうまくいかないと言っていると思いますか? どのようなエラーが発生していますか...