Ошибки управления диаграммой ASP.NET в средстве просмотра событий

Question

Некоторое время я использовал элементы управления диаграммой ASP.NET на установках win2k3 (32bit) без каких-либо проблем, но заметил, что в нашем новом окне win2k8 (64bit) я получаю предупреждение, отображаемое в средстве просмотра событий от управление графиком.

В моем файле web.config есть следующий тег, указывающий элементу управления Chart, где я могу хранить временные файлы:

<add key="ChartImageHandler" value="storage=file;timeout=20;dir=c:\TempImageFiles\;" />

Ниже приведено предупреждение, выданное элементом управления:

---

Код события: 3005 Сообщение о событии: произошло необработанное исключение. Время события: 7.10.2009 14:40:03 Время события (UTC): 7.10.2009 14:40:03 Код события: 237c3b208962429e8bbc5a48ffd177f0 Последовательность событий: 2860 Возникновение события: 26 Код детали события: 0

Информация о приложении: Домен приложения: / LM / W3SVC / 2 / ROOT-1-128993655360497729 Уровень доверия: Полный Виртуальный путь к приложению: / Путь к приложению: C: \ data \ sites \ mydomain.com \ Название машины: 231692-WEB

Информация о процессе: Идентификатор процесса: 4068 Имя процесса: w3wp.exe Имя учетной записи: NT AUTHORITY \ NETWORK SERVICE

Информация об исключении: Тип исключения: ArgumentException Сообщение об исключении: изображение не найдено.

Запрос информации: URL запроса: http://www.mydomain.com/ChartImg.axd?i=chart_0_3.png&g=bccc8aa11abb470980c60e8cf1e71e15 Путь запроса: /ChartImg.axd Адрес хоста пользователя: мой домен ip Пользователь:
Аутентифицировано: Ложь Тип аутентификации:
Имя учетной записи потока: NT AUTHORITY \ NETWORK SERVICE

Информация о теме: ID темы: 7 Имя учетной записи темы: NT AUTHORITY \ NETWORK SERVICE Выдает себя за: Ложь Трассировка стека: в System.Web.UI.DataVisualization.Charting.ChartHttpHandler.ProcessSavedChartImage (контекст HttpContext) в System.Web.UI.DataVisualization.Charting.ChartHttpHandler.System.Web.IHttpHandler.ProcessRequest (контекст HttpContext) в System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute () в System.Web.HttpApplication.ExecuteStep (шаг IExecutionStep, логическое и завершено синхронно)

---

Стоит отметить, что ВСЕ изображения графиков правильно отображаются на экране, поэтому я не уверен, когда / где возникает ошибка, когда изображение не найдено. Это 64-битная проблема?

Спасибо, Рич

Answer 1

У меня возникала такая же ошибка всякий раз, когда пользователи пытались скопировать или перетащить диаграмму из IE в документ Word. По умолчанию сервер удаляет графические изображения сразу после их доставки в браузер пользователя, и IE, похоже, не копирует данные кэшированного изображения. Я не уверен в механике, стоящей за этим, но либо при копировании, либо при вставке изображение должно быть снова получено с сервера. Проблема была решена путем изменения записи в web.config на:

<add key="ChartImageHandler" value="storage=file;timeout=20;dir=c:\TempImageFiles\;deleteAfterServicing=false;" />

Answer 2

По моему опыту, вы получите это сообщение об ошибке, если пользователь попытается распечатать веб-страницу, если deleteAfterServicing не имеет значения false в файле web.config, поскольку изображение будет удалено.

Кроме того, если deleteAfterServicing = false, если пользователь1 создает диаграмму, тогда пользователь2 создает диаграмму, перезаписывая изображение диаграммы, пользователь2 может успешно распечатать диаграмму, но пользователь1 вызовет исключение.

Answer 3

Я потратил неделю на изучение этой проблемы, и, похоже, никто не знает, почему я получаю предупреждающие сообщения в средстве просмотра событий.

Задавали этот вопрос и на основных форумах MS Chart, но не повезло. ссылка здесь: http://social.msdn.microsoft.com/Forums/en-US/MSWinWebChart/thread/75f50254-0f02-4a73-bfbe-afab31f15f77

Будет помечен как ответившийся только для того, чтобы закрыть вопрос, но будет обновляться в будущем, если я когда-нибудь найду ответ. Я подозреваю, что это происходит с большим количеством людей, но поскольку все на внешнем интерфейсе выглядит нормально, никто никогда не проверяет журналы, поэтому они могут не осознавать, что это происходит с ними.

Answer 4

Вы используете это на собственном сайте IIS7 или на сайте IIS7, работающем в режиме совместимости с ASP.NET 2.0?

Вполне возможно, что IIS просто немного многословен, когда ведет журнал или регистрирует наличие проблемы, а затем возвращается к устаревшему режиму поддержки - файлы .axd - это виртуальные файлы, которые обычно не существуют в на диске, они отображаются в качестве обработчиков в вашем файле web.config - обратите внимание, что IIS7 теперь поддерживает элемент <system.webServer>, и ваши обработчики должны отображаться там для новых сайтов, а не в разделе <system.web>.