サーバーのホットパッチ：アップロードされたアセンブリから型を動的に読み込む
現在取り組んでいるプロジェクトでは、一部のC＃クラスがソースコードとしてSQL Serverデータベースレコードに保存され、必要に応じて CSScript 。これは、これらのクラスが存在するアセンブリを置き換えるためにサーバーを停止する必要がないように行われています。
これは原則として良い考えのように思われましたが、このスキームのコストはさまざまなレベルでのメリットを上回っており、現在、他の可能な救済策を追求しています。
以前は、この種の「遅延バインディング」が必要な場合、Activator.CreateInstance()を使用して、必要なタイプをインスタンス化して使用していました。通常、この機能は、XML構成ファイルを使用して適切なアセンブリを接続するファクトリメソッドの背後に隠します。
したがって、私の完璧な世界では、サーバーにホットパッチを適用する場合、アセンブリをサーバーにコピーし、XMLファイルを編集して新しいアセンブリを参照し、次に、これらの型のインスタンスがファクトリメソッドを介して要求されるとき、サーバーは古いアセンブリではなく新しいアセンブリからインスタンスを自動的に受信します。
とはいえ、実行中のシステムでこれを試したことはありません。私は常に、実行されていないプログラムで、一種の貧乏人のプラグインシステムとして使用してきました。 [〜＃〜] mef [〜＃〜] のようなことは知っていますが、MEFを使用する必要がなかったため、ここでMEFがどのように適用されるのかわかりません。
私の質問は簡単です。何が欠けていますか？これは私が思っているほど簡単ではありませんか？元のタイプがロードされた元のDLL）のアプリドメインをアンロードしていないため、これは失敗しますか？アルゴリズムが警告なしに突然Skynetになりますか？
要するに、もっと良い方法はありますか？
あなたがやろうとしていることに応じて、それはより簡単です。
IISは、ファイルが変更されたことを検出すると、自動的にアプリプールを再起動します。実行中のサーバーにパッチを適用するだけの場合は、新しいDLLをプッシュして、アプリプールを循環させます。
元のタイプがロードされた元のDLL）であるアプリドメインをアンロードしていないため、これは失敗しますか？
古いDLLと新しいDLLが同じバージョンである場合、それらが非常に悪いことをするだろうと私は確信しています。同じタイプの完全修飾名ですが、バージョンが異なるとニースが再生されます。これは そうではない のように見えます。
何が欠けていますか？
気をつけなければならないことの1つは、構成からの読み込みは負荷の高い操作になる傾向があることです。これは、コードまたは基盤となるAPIによってキャッシュされる操作です。工場で新しいターゲットを確認することは、微妙なバグの迅速かつ簡単な原因である可能性があります。また、コードがFactory.Createの連続呼び出しが同じ具象型を返すと想定する場合の同時実行性の問題もあります。
しかし、最終的にはActivator.CreateInstanceに要約されます。