ASP.NET 3.5 アプリケーションのログに、ときどき (毎日 1 回程度) 次の種類のエラーが表示されます。
- ビューステートが無効です
- 無効なポストバックまたはコールバック引数
これらは、ASP.NET アプリケーションで時々発生するものですか? 問題の原因を診断するために多くの時間を費やすことをお勧めしますか?
Richard E
質問する
29714 次
10 に答える
51
まあそれは依存します。無効なビューステートは、さまざまな理由で発生する可能性があります。
- Viewstate が大きすぎて、ユーザーがページでポストバックを発生させる前にレンダリングが完了していません。通常、この修正は、ポストバックをトリガーするすべてのコントロールを無効にし、ページの読み込みが完了したらクライアント側で有効にすることです - http://blogs.msdn.com/tom/archive/2008/03/14/validation-of-viewstate- mac-failed-error.aspx
- ビューステート MAC を使用していますが (セキュリティ上の理由から使用する必要があります)、マシン キーを設定しておらず、アプリケーション プールがリサイクルされて新しいものを生成しています。ViewStateUserKey を設定することを忘れないでください。
- 非表示のフォーム フィールドを切り捨てる古いバージョンの IE を Mac で使用しているユーザーがいます。この場合、viewstate をページからsession stateに移動する必要があります。
- Viewstate MAC の問題は通常、Web ファームにいて、web.config でマシン キーを設定するのを忘れていることを示しています。ただし、これを行った場合は、誰かが悪いことをしようとしている可能性があります (コメントを投稿するボット、無効化されたコントロールのイベントをトリガーしようとしている人など)。潜在的なセキュリティの問題を除外するためだけに、これらの原因を追跡する必要があります。
何をするにしても、ビューステートまたはイベントの検証をオフにしないでください。
于 2009-02-23T09:36:17.400 に答える
7
問題の 1 つは、ユーザーのルーターがフォーム フィールドを切り捨てることに関係している可能性があります。これを回避するには、web.config で MaxPageStateFieldLength を小さい数値 (100 など) に設定すると、ViewState が小さなチャンクに分割されます。やり方はとても簡単で、この記事で詳しく説明しています。
于 2009-02-23T09:42:22.377 に答える
4
例外は、ときどき「ただ発生する」わけではありません。それらは常に正当な理由で発生し、そのうちのいくつかは他の回答に既にリストされています。
ただし、ViewState の問題を軽減するには、ViewState を完全に無効にすることを検討してください。ASP.NET 開発者として、ViewState がデフォルトであるため必要のないあらゆる場所で ViewState を使用する傾向があります。通常、コントロールの使用を検討する前に、静的 html の使用を検討します。コントロールを使用する場合は、本当に ViewState を有効にする必要があるかどうかを検討してください。無効にするとページの読み込み時間が短縮されることが多いため、可能であれば無効にしてください。
デフォルトで無効にして、人々がこのように考えるように強制されたらいいのにと思いますが、そうではありません。
コメントへの回答の更新:
頭のてっぺんに、ViewState をオフにする 3 つの機会が思い浮かびました。
ポストバックごとにデータが読み込まれる場合は、ViewState を無効にします。これは、AJAX 対応サイト (UpdatePanel の種類ではなく実際のAJAX です ;) を構築している場合によく当てはまります。通常、最初の読み込み時にデータを読み込み、次に AJAX 要求を使用してデータを再読み込み/更新します。場合によっては、ViewState を無効にするという唯一の目的で、アクセスのたびにデータをロードし、代わりにサーバーにデータをキャッシュすることさえあります。
本当に静的なコンテンツにデータバインドする場合は、ViewState を無効にすることも検討できます。データベース内の小さな静的ベースデータ テーブルなどにデータ バインドされているリストを見つけることがあります。これは危険な場合がありますが、データが変更されないと確信している場合は、データを静的コンテンツとしてページに移動する可能性があります (別のコントロールでラップできるため、データの静的コピーが複数作成されることはありません)。 ）。ただし、データが変更された場合は、手動で変更する必要があります。
ラベルなどの単純なコントロールは、多くの場合、ViewState を無効にするのに適しています。
最後に、ASP.NET MVC フレームワークに切り替えて、これらの問題に永遠に別れを告げることができます。他の問題に直面したとしても、それは私が計画していることです。;)
于 2009-02-23T09:53:08.937 に答える
4
BlowDart には、無効なビューステートの問題に対する正しい答えがあります。おそらく、アプリ プールがリサイクルされ、暗号化キーが変更されている可能性があります。
サポートについては、次の投稿を参照してください。
于 2009-08-19T14:19:03.717 に答える
1
前者についてできることはあまりありません - 私はそのような例外をトラップし、「あなたがいたページは期限切れです。これは通常、あなたがページを再訪問しようとしたときに発生します。すでにデータを入力していました。」
後者は、UpdatePanels を使用するかなり大きなページで最もよく見られます。ページの読み込みが完了する前にユーザーがポストバック (またはコールバック) したときだと思うので、ページの最後にタグ付けされたすべての JavaScript がまだ実行されていません。
繰り返しますが、エラー ページに適切にわかりやすいメッセージを表示する以外に、それらについてできることはあまりありません。
于 2009-02-23T09:28:58.387 に答える
1
この種の例外がログにスローされ、ここにリストされている他のものとはまったく異なる原因がありました。問題の一部である非常に大きな ViewState がありました。しかし、それは別の問題と組み合わさって、これらの例外 (および IIS からの時折の不適切な応答) を引き起こします。
私が取り組んでいるコードベースには、ダブルクリックを回避するためのいくつかの凝ったコードがあり、その一部として、最初のクリック後にボタンを無効にするすべてのボタンのクリックイベントの JavaScript にいくつかのものを追加し、通常のポストバックを行います。しかし、私のボタンのいくつかには、.NET によって自動的に生成されたポストバック呼び出しが既にあったため、そのようにポストバックを呼び出すことは問題でした。そのため、ポストバックが 2 回発生し、そのうちの 1 つに無効な ViewState がありました。余分なポストバックを削除すると、例外が停止しました。
ViewState のサイズを大幅に縮小する必要があることはわかっていますが、これは大規模なレガシー コード ベースであり、そのような変更は非常に侵襲的です。
于 2013-12-04T18:18:09.197 に答える
0
このエラーを無視するのはおそらく良い考えではありません。上記のすべての回答に加えて、ビューステートの大きさを調べることを検討することをお勧めします。大きなビューステートは、プロキシサーバーによって切り捨てられる可能性があります。
ビューステートが大きい場合は、ASP.netトレースを使用して、ビューステートを使用しているコントロールと、これをオフにできる場所を確認することをお勧めします。
于 2009-08-06T20:47:52.123 に答える
0
このブログ投稿のWayneWalterBerryによると、別の犯人がページにXHTML準拠のマークアップを持たずにIE8でXHTMLDoctypeを使用している可能性があります。これにより、IE8はスクランブルされたパラメーターをscriptresource.axdに送信し、無効なビューステート例外をスローする可能性があります。
彼は、すべてのjavascriptブロックが// <![CDATA[]]>Doctypeでラップされていることを確認するか、単に変更することをお勧めします（これにより、ページで他のcss /スタイルの問題が発生する可能性があります）。
于 2009-08-29T16:07:39.453 に答える
-2
更新: Microsoft は、IE 8 の次のバグ修正でこの問題が修正されることを発表しました:
http://blogs.msdn.com/ieinternals/archive/2010/04/01/IE8-Lookahead-Downloader-Fixed.aspx
于 2010-04-09T06:35:09.713 に答える