Ошибка WCF - отсутствует элемент детализации - PullRequest
0 голосов
/ 05 августа 2011

У нас есть собственное поведение обработки исключений (реализующее IErrorHandler) в нашем решении, которое по существу использует Automapper для преобразования исключений в сбои.

Это хорошо работает с первого дня. Однако мы только что заметили, просматривая ServiceTraceViewer(просматривая журналы сервера, а не клиента) на нашем общем сервере разработки, что при любых ошибках, возвращаемых нашими сервисами, отсутствует элемент detail.

При запуске точно такого же кода и конфигурации на моем компьютере разработчика, элемент detail заполнен правильно,Как я уже говорил, файлы конфигурации (поведения, привязки) идентичны на обеих машинах.Обе конфигурации действительно включают includeExceptiondetailsInFaults = true.

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

Моя машинная установка соответствует стандарту 2008R2 (64 бита).Рассматриваемый сервер также является стандартом 2008R2 (64 бит).

Я могу опубликовать выдержки кода, если это необходимо, но в первом случае есть ли что-то, что могло бы позволить то, что мы видим?1014 *

1 Ответ

0 голосов
/ 08 августа 2011

Не на 100% уверен насчет этикета. Это ответ, я думаю, на мою конкретную марку глупости. Может быть, кто-то еще будет таким глупым, тогда к ним относится ответ ...

Я был уверен, что сравнил все (я указал точно такой же код / ​​конфигурацию). Но файл конфигурации поведения я просто дал быстрый визуальный. После того, как ко мне подошел другой разработчик, я понял, что локальные файлы НЕ совпадают с файлами сервера. Doh!

На самом деле к файлам сервера добавлялась одна дополнительная строка на шаге пост-сборки - запуск другого пользовательского поведения, которое реализовало IErrorHandler в дополнение к поведению IErrorHandler, которое мы уже используем для ведения журнала и т. Д.

Полагаю, сейчас я собираюсь открыть еще один вопрос, который ищет ответ на подход о наличии нескольких вариантов поведения, реализующих один и тот же интерфейс и не загрязняющих функциональность друг друга (например, возвращая ошибки).

...