15

現在開発中の C#/ASP.NET の Web サイトがあります。本番環境では、バグを修正して機能を追加するため、1 日のうちに頻繁にリリースを行いたいと考えています ( http://toni.org/2010/05/19/in-praise-ofのように)。 -continuous-deployment-the-wordpress-com-story/ )。

サイトの新しいバージョンをアップロードしたり、単一のファイルを変更したりすると、現在ログインしているユーザーが追い出され、フォームなどを最初からやり直すようになります. .NET サイトのユーザーに干渉することなく展開できる秘訣はありますか?

4

5 に答える 5

5

これが表示される理由は、アプリケーション プールをリセットして、全員のセッションをリセットしているためです。

最もクリーンなルートは、セッションをセッション状態サーバーにオフロードするか、セッションの使用を最小限に抑えることです。

これを回避する 1 つの方法は、セッションをオフロードできない場合、常に新しい仮想ディレクトリにデプロイすることです。公開 URL は、最新バージョンにリダイレクトされるだけです。すでにログインしているすべてのユーザーは引き続き古いバージョンを使用しますが、新しいユーザーは新しいバージョンを使用します。

于 2010-05-19T19:31:33.790 に答える
5

構成ファイル、アプリの bin フォルダーの内容などに変更を加えると、アプリケーションと共に ASP.NET ワーカー プロセスが再起動します。

これにより、セッションが削除され、ユーザーが追い出されます。

解決策は、デフォルト以外のセッション ストレージ メソッドを使用することですInProc。これは、セッション状態モード
を設定することで実現できます。およびオプションは、問題に対する非常に優れた解決策を提供します。SqlServerStateServer

SqlServerモードは比較的簡単にセットアップして起動して実行できます。(基本的には、データベースを作成し、aspnet_regsql を実行してから、構成に指定するだけです。) MS SQL Server がない場合、または使用したくない場合は、 を使用するStateServerか、独自のプロバイダーを作成して使用できます。Customモード。

SqlServer唯一の制限は、シリアライズ可能な値をandStateServerモードでのみ保存できることです。

于 2010-05-19T19:56:37.113 に答える
0

Webサーバーのアプリケーションプロセスが再開されたため、ユーザーが蹴られたと思います。デフォルトでは、ユーザーセッションはメモリに保存され、セッションデータは強制終了されます。セッションプロバイダーは、web.configで構成可能なオプションです。外部の（Webアプリケーションプロセス外の）セッションプロバイダーを選択することは、期待することに向けた一歩です。

于 2010-05-19T19:32:36.017 に答える
0

これを実現するには、次の 2 つの方法があります。

  1. セッションをまったく使用しないでください。（認証にクッキーを使用する場合があります）
  2. 別のセッション状態モードを使用してください。状態サーバーまたは SQLServer。http://msdn.microsoft.com/en-us/library/ms178586(v=VS.80).aspx

どちらの方法でも、アプリケーションを複数のサーバーで実行してパフォーマンスやフェイル セーフ クラスタリングを実現できる柔軟性も得られます。

于 2010-05-19T19:43:24.057 に答える
0

Session オブジェクトに格納する内容によっては、Global.asax の Session_Start ハンドラーで再構築できる場合があります。以前は、セッションにユーザーの ID のみを実際に保存する内部アプリケーションでこれを行っていたので、承認 Cookie を使用してセッションを再作成することができました。

これを行う場合に留意すべきことの 1 つは、ユーザーがフォームを読み込んで昼食に出かけ、不在中にそのページを更新したとします。デスクに戻ってフォームを送信すると、古いバージョンのフォームが新しいコード ビハインドに送信されます。

于 2010-05-19T19:43:24.150 に答える