Я должен проигнорировать случайную Недопустимую ошибку состояния отображения?
Я получил то же сообщение об ошибке (в XCode 8), хотя приложение работает нормально (в симуляторе и на устройстве).
Я нашел проблему: на моей раскадровке, используя панель контура документа, я щелкнул каждый отдельный UIImage и посмотрел на инспектора атрибутов для каждого UIImage - в разделе «Вид изображения» - обнаружил, что один UIImage пустое имя файла (вместо имени файла .png, содержащего изображение). При повторном выборе имени файла .png из раскрывающегося списка было исправлено сообщение об ошибке.
8 ответов
Хорошо это зависит. Недопустимое состояние отображения может произойти по ряду причин.
- Состояние отображения является слишком большим и не закончило представлять, прежде чем пользователь вызывает обратную передачу на странице. Фиксация должна обычно отключать все средства управления, которые инициировали обратные передачи и включают им сторону клиента, после того как страница закончила загружаться - видят http://blogs.msdn.com/tom/archive/2008/03/14/validation-of-viewstate-mac-failed-error.aspx
- , Вы используете состояние отображения MAC (и необходимо быть из соображений безопасности), но Вы не установили ключ машины, и пул приложений переработал генерацию новой. Не забывайте устанавливать ViewStateUserKey.
- Кто-то использует старую версию IE на Mac, где это усекает скрытые поля формы. В этом случае необходимо будет переместить состояние отображения из страницы в состояние сеанса .
- Состояние отображения, проблемы MAC обычно указывают, что Вы находитесь на веб-ферме и забыли устанавливать ключ машины web.config. Однако при выполнении этого затем, это - вероятно, кто-то пытающийся сделать плохие вещи (боты, добавляя комментарии, кто-то пытающийся инициировать события для отключенных средств управления и т.д.), причина их должна быть разыскана, если только исключить потенциальные проблемы безопасности.
Независимо от того, что Вы делаете , не делают , выключают проверка события или состояние отображения.
Одна проблема может относиться к пользовательским маршрутизаторам, усекающим поля формы. Путь вокруг этого состоит в том, чтобы установить MaxPageStateFieldLength на небольшое количество (как 100) в web.config, и ViewState разбит в маленькие блоки. Очень просто сделать, и , эта статья объясняет это полностью.
Исключений "просто не происходит" время от времени. Они всегда происходят по допустимым причинам, некоторые из которых уже перечислены в других ответах.
Однако для облегчения проблем с ViewState рассматривают отключение его в целом. Как разработчики ASP.NET мы часто склонны использовать ViewState во всем виде мест, где он не необходим, потому что это - значение по умолчанию. Я обычно думаю об использовании статического HTML, прежде чем я рассмотрю использование управления. Если Вы действительно решаете использовать управление, думают о том, если ему действительно нужен ViewState, который будет включен. Отключение его часто приводит к лучшему времени загрузки страницы, поэтому если Вы можете, сделать это.
мне жаль, что это не было отключено по умолчанию, таким образом, люди были вынуждены думать этот путь, но это не.
Обновление для ответа на комментарий:
Из вершины моей головы я придумываю 3 возможности выключить ViewState.
-
Отключают ViewState, если данные загружаются на каждой обратной передаче. Это будет часто иметь место при создании включенных сайтов Ajax (это реально Ajax не, что вид UpdatePanel ;)), где Вы обычно загружаете данные по первой загрузке и затем перезагружаете/обновляете данные с помощью запросов Ajax. В некоторых случаях Вы могли бы даже загрузить данные по каждому посещению к единственной цели отключить ViewState и затем кэшировать данные по серверу вместо этого.
-
можно также считать отключение ViewState, если Вы связываете с данными к содержанию, которое действительно статично. Иногда я нахожу список, который связан с данными к маленькой статической basedata таблице в базе данных или чем-то как этот. Теперь, это может быть опасно, но если я убежден, что изменение привычки данных, я мог бы переместить данные в страницу как статическое содержание (Вы могли перенести его в отдельное управление, таким образом, у Вас не будет нескольких статических копий данных). Но если данные затем изменяются, необходимо будет изменить его вручную.
-
Простые средства управления, такие как Маркировки часто являются хорошими кандидатами на отключение ViewState.
Наконец Вы могли переключить на ASP.NET платформу MVC и помахать на прощание к этим проблемам навсегда, это - то, что я планирую сделать, даже если я столкнусь с некоторыми другими проблемами. ;)
Нет очень, можно сделать о первом - я захватываю такие исключения и возвращаю пользователя к ошибочной странице с сообщением вроде "Страницы, Вы шли, истек. Это обычно происходит, когда Вы пытаетесь пересмотреть страницу, где Вы уже ввели данные".
я вижу последнего большинство на довольно большие страницы то использование UpdatePanels. Я думаю, что это - когда пользователь отправляет назад (или возможно перезванивает), прежде чем страница закончила загружаться, таким образом, не весь JavaScript, который наклеен конец страницы, работал все же.
Снова, нет очень, можно сделать о них кроме шоу соответственно дружественное сообщение на ошибочной странице.
Вероятно, игнорировать эту ошибку - не лучший вариант. В дополнение ко всем приведенным выше ответам вы можете подумать о том, насколько велико ваше состояние просмотра. Большое состояние просмотра может быть усечено прокси-сервером.
Если у вас большое состояние просмотра, может быть хорошей идеей использовать трассировку ASP.net, чтобы увидеть, какие элементы управления используют состояние просмотра и где вы можете отключить это.
У BlowDart есть правильный ответ на проблему недопустимого состояния просмотра. Вероятно, ваш пул приложений перерабатывается и изменяется ключ шифрования.
См. Эти сообщения для поддержки:
Erratic Invalid Viewstate issue в приложении .NET
Обеспечение постоянного входа пользователя в систему с членством в ASP .Net
Согласно Уэйну Уолтеру Берри в этом сообщении в блоге, еще одним виновником может быть использование документа XHTML в IE8 без наличия на странице разметки, совместимой с XHTML. Это может привести к тому, что IE8 отправит скремблированные параметры в scriptresource.axd и выдаст исключение недопустимого состояния просмотра.
Он рекомендует убедиться, что все блоки javascript заключены в оболочку // или просто изменение типа документа (что может вызвать другие проблемы css / стилями на вашей странице).
Обновление: Microsoft объявила, что следующее исправление ошибки для IE 8 устраняет эту проблему:
http: //blogs.msdn. com / ieinternals / archive / 2010/04/01 / IE8-Lookahead-Downloader-Fixed.aspx