Вызов Silverlight 4 wcf завершается сбоем на сервере, но не при отладке

Question

У меня есть приложение Silverlight 4, которое общается с классом 'manager', который общается со службой WCF (.net 4), которая использует библиотеку Microsoft.ApplicationBlocks.Data для связи с моей базой данных SQL.

Моя проблема с исключениями, не связанными с приложением Silverlight.

Что происходит, происходит сбой при вставке в базу данных, создается исключение SQLException, а затем выдается ошибка, генерируемый код ссылки на службу, используемый Manager, который в обработчике завершенных событий обнаруживает, что свойство Error имеет значение ненулевой. Это создает событие в приложении Silverlight, которое отображает пользователю сообщение о том, что произошла ошибка.

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

Если я сгенерирую ссылку на службу из службы wcf, работающей на сервере (не локально), и использую локальный экземпляр моего приложения Silverlight, он также будет работать правильно, что заставляет меня думать, что ошибка возникает в ссылке на службу ( сгенерированный код) и связь Silverlight.

Служба размещается в хост-приложении с «ручным кодированием», а приложение Silverlight на сервере размещается в IIS. Они оба используют http, а не https.

Я искал в Интернете, но ничего не нашел, относящийся к этой ситуации. Я не убиваю объекты, поэтому предотвращаю возвращение исключений несуществующим объектам.

Короче говоря, Менеджер правильно получает и выдает событие в моей локальной системе, но не при развертывании на сервере.

WCF Эксперты нужны, пожалуйста!

Answer 1

Итак, после еще нескольких бесполезных поисков мой коллега создал тестовое приложение, в котором он создал собственный класс Silverlight Fault Contract на основе этого примера: http://msmvps.com/blogs/theproblemsolver/archive/2009/01/27/returning-exception-information-to-a-silverlight-client-through-wcf.aspx

Хотя это очень помогло получить конкретную ошибку отслужба вместо обычного мусора, который извергает Silverlight, мы все еще не могли отобразить ошибку на экране.

Мое предыдущее предположение, что связь не удалась, было неверным.Вместо этого это был просто факт, что результат не имел никакого влияния на Поток пользовательского интерфейса.Мы использовали Диспетчер, чтобы вернуться к потоку пользовательского интерфейса:

Deployment.Current.Dispatcher.BeginInvoke(
            () =>
            {
                //throw event to window which shows error window
            }
            );

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

Если кто-то, кто больше знает о технических особенностях этого случая, прочтетПожалуйста, будьте любезны объяснить, что на самом деле здесь произошло.