.netアセンブリのホットデプロイ

Question

プロダクションサーバー上でWindowsサービスとして実行されているアプリケーションがあります。アプリケーションは、主に展開の境界にある複数のアセンブリに分割されます。ホットフィックスのアプリケーションアセンブリへの展開を合理化したいと思います。現在、私はホットフィックスを展開するために以下の手順を実行します。 （私たちは、ステージングのための生産環境の複製を持っているので、すべては二度行う必要があります）（コピー

バックアップ現在展開DLLサービスを停止し、修正プログラムを置き換え

1. ログインサーバー
2. に既存のDLLを超える修正プログラム）
3. 再起動サービス
4. バック予期せぬロード・エラーの場合のロール（まだ、起きていない）

私が望むのは、dllをプリセットフォルダにアップロードして（SFTP）、アプリケーションに新しいDLLを受けさせることだと思います。

私が考えた解決策は、サーバー上で別々のサービスを実行することです。それを修正プログラム展開サービスと呼ぶことにしましょう。新しいファイルのファイルシステムを監視し、上記のリストからステップ2〜6を実行します。

洞察が得意です。私は、展開摩擦を減らすだけでなく、他の選択肢にもオープンしています。

Answer 1

おそらく別のサービスをお持ちの方が最適です。

これは、単一のサービスでこれを実行する可能性があります。しかし、サービスを自己更新するために必要となる「トリック」は実装するのが少し難しい。

あなたがしなければならないことは、非常に軽いシェルサービス以外のサービスとして始めることです。次に、分離された孤立したAppDomainを起動し、そのappdomainにサービスのアセンブリをロードし、初期化して実行させることができます。

その後、新しいアセンブリを[FileSystemWatcher経由で更新フォルダにコピーするなど、サービスが拾うことができるイベントを介してトリガする可能性があり、ネットワーク経由で明示的に通知するなど]）、内部AppDomainのタイプを停止するように指示する方法をトリガーする必要があります。AppDomainをアンロードします。この時点で、上記のステップ3 & 4を実行できます。

サービスは別個のAppDomainにあるため、サービスを停止せずに1つの実行可能ファイルで実行することができます。これは、AppDomainを再ロードして初期化を再実行するだけです。 AppDomainがアンロードされると、AppDomainがロードされたアセンブリもアンロードされます。

ここで唯一必要となるのは、構築されたAppDomainからメインAppDomainに型を渡さないようにするか、メインAppDomainにアセンブリを読み込む必要があることです。これにより、実行時にそれらを更新できなくなります。

Answer 2

「ホットプラグ」アセンブリの良いオプションとして、Castle Windsorを見てみましょう。

これは高度にサポートされているIoC/DIフレームワークで、実際にファイルをターゲットマシンに移動することを除いて、言及した多くのタスクに役立ちます。実際の配管工事はCWでもうまく処理されます。

Answer 3

ビルドサーバーからは、PowerShellスクリプトを使用してサービスをリモートで停止し、新しいファイルをコピーしてサービスを再起動します。