実行中のasp.netアプリにパッチを適用する方法のサンプルを誰かが持っていますか？私が想定しているシナリオは、アプリが既知の中央サーバーで新しいバージョンを探すことができるというものです。新しいファイルを一時的な場所にダウンロードしてから、パッチを適用します。
私が見ることができる問題は、ファイルの変更がファイルウォッチャーによって取得され、現在のパッチ適用プロセスを停止するアプリドメインをリロードすることです。書き込まれた各ファイルがアプリのリロードをトリガーすると思います。
1960 次
4 に答える
3
パッチを当てるとはどういう意味ですか？
更新する場合は、更新ファイルをアプリケーションディレクトリにコピーするだけです。現在アクティブなリクエストは、アプリケーションの最後にコンパイルされたバージョンを使用して完全に処理され、その後、結果のリクエストを処理するために再コンパイルされます。特別なことは何も必要ありません。
于 2009-07-17T20:46:23.830 に答える
3
特定のファイルを監視している場合を除き、アプリケーションの速度を低下させることなく、既存の aspx ファイルを更新できます。次にユーザーがブラウザを更新すると、ページが更新されます。ただし、ページに追加のサーバー コントロールを追加し、DLL がまだ更新されていない場合は、問題が発生することに注意してください。
アプリケーションの web.config ファイルまたは DLL ファイルを更新すると、ASPNET ワーカー プロセスのリロードがトリガーされ、新しいユーザーは通常予想される「最初のラグ」に苦しむことになります。
このプロセスが心配で、少しの「ダウンタイム」を許容できる場合は、次のことを行うスクリプトを作成することをお勧めします。
App_Offline.htm という名前のファイルを Web アプリケーションのルートにアップロードします。IIS はすぐにこのファイルを確認してユーザーをリダイレクトし、.NET 処理は行いません。ルート フォルダーに App_Offline_Disabled.htm という名前のファイルを保持し、適切なタイミングで名前を変更することもできます。
更新が必要なすべてのファイルをコピーし、必要に応じて上書き/名前変更/コピーします。
IIS がユーザーを更新されたアプリケーションに誘導し始めるように、App_Offline.htm ファイルを削除 (または名前を変更) します。スクリプトの実行を見ている場合は、自分で Web サイトにアクセスして、その「最初の読み込み」のペナルティを受けることもできます。これにより、エンド ユーザーはいつものように素晴らしく鮮明に表示されます。
繰り返しますが、この方法でサイトのダウンタイムを許容できるかどうかはわかりませんが、プロセス自体は簡単にスクリプト化して、優れた自動化タイプのプロセスを提供できると思います.
于 2009-07-17T21:07:59.870 に答える
0
filewatcher イベントが発生したときにバージョン情報を確認するだけです。アセンブリのバージョンが、パッチ適用を検討しているアクティブなアセンブリと異なる場合は、コピーを続行します。そうでない場合は、単にイベントを無視します。また、実際のバージョン変更がない場合に、ファイルが取得されている一時ディレクトリにコピーするのはなぜですか?
于 2009-07-17T20:57:47.627 に答える
0
これを行う自動化された方法はわかりません。サーバーに変更をプッシュする自動化されたビルド スクリプトに頼る方が簡単なようです。
外部プロセスでセッション状態を保持する場合、ユーザーが追い出されることなくサイトを更新できます (再コンパイルが発生します)。再コンパイルを待つため、ロード時間が長くなるだけです。
于 2009-07-17T20:49:21.450 に答える