2

私たちには解決できない問題があります。それは、エンド ユーザーが中断することなく日中にコードをプッシュする方法です。私は開発者で、システム部門と協力して働いています。

セットアップ: 3 台の Windows 2008 IIS 7 ボックス - 1 台はダウン ノード、残りの 2 台は稼働中 (構成を共有)、3 台すべてが BigIP の背後にあります。私のサイトは、すべて .NET 2.0 の下に複数の Web アプリケーションを持つ 1 つの Web アプリケーションとしてセットアップされています。ビューステート用のマシンキーが設定された状態サーバーを使用しています。以前は 1 台のライブ マシンしかなく、BigIP の背後にはなかったため、この設定は比較的新しいものです。この設定に移行する理由の 1 つは、シームレスなプッシュのためでした。

私がやっていること: ウェブアプリケーションの 1 つにコードを変更しています。これを行うには、ダウン ノードに変更を加え、変更をテストしてから、アップ ノードに複製します。

私が経験していることは、コードのどの部分が変更されるかによって異なります。たとえば、webconfig の値を変更します。エンド ユーザーがポストバックすると、webconfig で新しい値を使用するという点で、すべてがうまく機能します。私たちはこれがとても好きです！また、シームレスな特定の方法で dll コードを変更することもできます (バックエンドのロジックを変更する)。

しかし、私たちを本当に悩ませている問題は、フォームに新しいラベルを追加することです。これを行うと、.Net はユーザーが初めてフォームをロードしたときのように動作しますが、ビューステートはすべて保持されます。これを具体的に Page.IsPostBack プロパティまで追跡し、さらにリフレクションを介して _fPageLayoutChanged まで追跡しました。プッシュ経由で新しいコンテンツをフォームに追加すると、_fPageLayoutChanged = true になります。エンド ユーザーの経験では、コンテンツはまだそこにあり、ビューステートはまだそこにありますが、最初の読み込みで実行するアクションはすべて実行され、実行しようとしていたイベントはフックされませんでした。たとえば、メモを保存するためにボタンを押した場合、メモは画面に表示されたままですが、ボタン クリック イベントが発生しなかったため、メモは保存されません。ページのアーキテクチャに応じて、

Web からの IsPostBack のコードは次のとおりです (これは、私たちを傷つけている最後の部分です)。

public bool IsPostBack {
    get {
        if (_requestValueCollection == null)
            return false; 

        // Treat it as postback if the page is created thru cross page postback. 
        if (_isCrossPagePostBack) 
            return true;

        // Don't treat it as a postback if the page is posted from cross page
        if (_pageFlags[isCrossPagePostRequest])
            return false;

        // If we're in a Transfer/Execute, never treat as postback (ASURT 121000)
        // Unless we are being transfered back to the original page, in which case 
        // it is ok to treat it as a postback (VSWhidbey 117747) 
        // Note that Context.Handler could be null (VSWhidbey 159775)
        if (Context.ServerExecuteDepth > 0 && 
            (Context.Handler == null || GetType() != Context.Handler.GetType())) {
            return false;
        }

        // If the page control layout has changed, pretend that we are in
        // a non-postback situation. 
        return !_fPageLayoutChanged; 
    }
}

最後の行のコメントは私を殺している.b / cなぜ彼らがその決定を下したのか説明していない.

さらに、エンド ユーザーに中断することなく日中にコードをプッシュしようとして、これによって妨げられたのは私たちだけだとは信じられません。私たちは何をすべきか途方に暮れています。IIS 設定を変更する必要がありますか? コードを再構築して、IsPostBack プロパティに依存しないようにします (ただし、IsPostBack が false の場合、.NET がイベントを正しく接続していないように見えるため、イベントは発生しません)。これを回避することは可能ですか？

4

1 に答える 1

0

多くの大規模なサイトでは、常に更新を展開しています。アマゾンはそれで最も知られているものの1つです。このスライド デッキを確認してください。

1 つの方法は、すべてのバージョンのコードを同時に実行できるようにし、「バージョン 1.2.3.4 で処理する必要がある」Cookie などの情報に基づいてリクエストをルーティングすることで、リクエストを処理するバージョンを決定することです。

もう 1 つのアプローチは、下位互換性をコードに組み込むことです。保守は困難ですが、必要なインフラストラクチャは大幅に少なくて済みます - 1 回限りのケースで問題ありません。

于 2012-03-21T16:31:17.893 に答える