Должен ли я игнорировать случайную ошибку в представлении "Недействительный"?
Время от времени (один раз в день или около того) мы видим следующие типы ошибок в наших журналах для приложения ASP.NET 3.5
- Недопустимое состояние просмотра
- Недопустимый аргумент обратной передачи или обратного вызова
Это что-то, что "просто происходит" от времени от времени к приложению ASP.NET? Кто-нибудь порекомендовал бы мы потратить много времени, пытаясь диагностировать, что вызывает проблемы?
Ответы
Ответ 1
Ну, это зависит. Недопустимое состояние просмотра может происходить по разным причинам.
- Viewstate слишком большой и не закончил рендеринг, прежде чем пользователь вызывает обратную передачу на странице. Исправление, как правило, отключает все элементы управления, которые запускают обратные вызовы и активируют их на стороне клиента после завершения загрузки страницы - см. http://blogs.msdn.com/tom/archive/2008/03/14/validation-of-viewstate-mac-failed-error.aspx
- Вы используете MAC-адреса viewstate (и вы должны быть по соображениям безопасности), но вы не установили машинный ключ, а пул приложений переработал, генерируя новый. Не забудьте установить ViewStateUserKey.
- Кто-то использует старую версию IE на Mac, где он обрезает скрытые поля формы. В этом случае вам нужно переместить viewstate из страницы в состояние сеанса.
- В представлении ViewState MAC обычно указывается, что вы находитесь в веб-ферме и забыли установить машинный ключ в web.config. Однако, если вы это сделали, возможно, кто-то пытается делать плохие вещи (боты, отправляющие комментарии, кто-то пытается инициировать события для отключенных элементов управления и т.д.). Причина их должна быть отслежена, если только исключить возможные проблемы безопасности.
Независимо от того, что вы делаете не, отключите проверку состояния просмотра или события.
Ответ 2
Одна из проблем может быть связана с тем, что маршрутизаторы пользователей обрезают поля формы. Способ вокруг этого заключается в том, чтобы установить MaxPageStateFieldLength на небольшое число (например, 100) в web.config, а ViewState разбивается на небольшие куски. Это очень просто сделать, и эта статья полностью объясняет.
Ответ 3
BlowDart имеет правильный ответ для проблемы с недопустимым представлением. Вероятно, ваш пул приложений перерабатывается и меняет ключ шифрования.
Смотрите эти сообщения для поддержки:
Ошибка ошибки в представлении в приложении .NET
Постоянная регистрация пользователя с членством в ASP.Net
Ответ 4
Исключения не "просто происходят" время от времени. Они всегда встречаются по уважительным причинам, некоторые из которых уже указаны в других ответах.
Однако, чтобы облегчить проблемы с ViewState, подумайте об отключении его вообще. Как разработчики ASP.NET мы часто склонны использовать ViewState во всех местах, где это не нужно, потому что оно по умолчанию. Обычно я думаю об использовании статического html, прежде чем использовать элемент управления. Если вы решите использовать элемент управления, подумайте о том, действительно ли нужно, чтобы ViewState был включен. Отключение его часто приводит к улучшению времени загрузки страницы, поэтому, если это возможно, сделайте это.
Я хочу, чтобы он был отключен по умолчанию, поэтому люди были вынуждены думать таким образом, но это не так.
Обновить ответ на комментарий:
В верхней части моей головы я придумал 3 возможности отключить ViewState.
-
Отключить ViewState, если данные загружаются при каждой обратной передаче. Это часто случается, если вы создаете сайты с поддержкой AJAX (этот реальный AJAX не тот тип UpdatePanel;)), где вы обычно загружаете данные при первом загрузке, а затем перезагружаете/обновляете данные с помощью запросов AJAX. В некоторых случаях вы даже можете загружать данные при каждом посещении с единственной целью отключения ViewState, а затем кэшировать данные на сервере.
-
Вы также можете рассмотреть возможность отключения ViewState, если вы привязываетесь к содержимому, которое действительно статично. Иногда я нахожу список, привязанный к базе данных, к небольшой таблице static basedata в базе данных или что-то в этом роде. Теперь это может быть опасно, но если я убежден, что данные не изменятся, я могу перенести данные на страницу в виде статического содержимого (вы можете обернуть его в отдельный элемент управления, чтобы у вас не было нескольких статических копий данных). Но если данные затем меняются, вам придется вручную их изменить.
-
Простые элементы управления, такие как ярлыки, часто являются хорошими кандидатами для отключения ViewState.
Наконец, вы можете переключиться на структуру ASP.NET MVC и навсегда прощаться с этими проблемами, что я планирую делать, даже если я столкнусь с некоторыми другими проблемами.;)
Ответ 5
Не так много, что вы можете сделать по отношению к первому - я задерживаю такие исключения и отказываюсь от пользователя на странице с сообщением в строке "Текущая страница, срок действия которой истек. Обычно это происходит, когда вы пытаетесь пересмотреть где вы уже ввели данные."
Я вижу последнее на большинстве больших страниц, использующих UpdatePanels. Я думаю, что когда пользователь отправляет назад (или, возможно, перезванивает) до того, как страница закончит загрузку, не все javascript, который помечается в конце страницы, еще не запущены.
Опять же, вы не можете сделать с ними ничего, кроме как показать подходящее сообщение на странице с ошибкой.
Ответ 6
Вероятно, не стоит игнорировать эту ошибку. В дополнение ко всем вышеперечисленным ответам вы можете рассмотреть вопрос о том, насколько велика ваша точка зрения. Большое представление может быть усечено прокси-сервером.
Если ваше состояние представления велико, может быть хорошей идеей использовать трассировку ASP.net, чтобы увидеть, какие элементы управления используют viewstate, и где вы можете отключить это.
Ответ 7
Согласно Уэйну Уолтеру Берри в this в блоге, другой виновник может использовать доктрину XHTML в IE8, не имея разметки, совместимой с XHTML на странице, Это может привести к тому, что IE8 отправит скремблированные параметры в scriptresource.axd и выбросит недопустимое исключение в представлении viewstate.
Он рекомендует следить за тем, чтобы все блоки javascript были обернуты с помощью // <![CDATA[]]>
или просто меняли doctype (что могло вызвать другие проблемы с CSS/стилями на вашей странице).
Ответ 8
У меня было такое исключение, которое было брошено в мои журналы и было совсем другое дело от других, перечисленных здесь. У меня действительно было очень большое ViewState, которое является частью проблемы. Но это было связано с другой проблемой, чтобы вызвать эти исключения (и, возможно, случайные плохие ответы от IIS).
В базе кода, над которой я работаю, есть несколько модных кодов, чтобы избежать двойных щелчков, и как часть этого он добавляет некоторые вещи в javascript каждого нажатия кнопки, которое отключает кнопку после первого щелчка, а затем делает обычная обратная передача. Но вызов такой обратной связи был проблемой, потому что некоторые из моих кнопок уже имели обратный вызов, созданный .NET автоматически. Таким образом, я получил двойные обратные копии, один из которых имел недопустимый ViewState. Удаление лишнего postback остановило исключения для меня.
Я знаю, что я действительно должен резко уменьшать размер ViewState, но это большая база устаревших кодов, и такое изменение было бы очень инвазивным.
Ответ 9
Недействительное состояние представления не имеет значения для вашего регистратора или для пользователей или вашего веб-сайта. Конечные пользователи никогда не видят эти ошибки.
чтобы избежать этой ошибки, попробуйте добавить следующее в Global.ascx:
void Application_Error(object sender, EventArgs e)
{
if (ex is HttpException && ex.InnerException is ViewStateException)
{
Response.Redirect(Request.Url.AbsoluteUri);
return;
}
}
для получения дополнительной информации проверьте следующую ссылку:
https://www.karpach.com/viewstateexception-invalid-viewstate.htm
Ответ 10
Обновление: Microsoft объявила, что следующее исправление ошибки для IE 8 устраняет эту проблему:
http://blogs.msdn.com/ieinternals/archive/2010/04/01/IE8-Lookahead-Downloader-Fixed.aspx