Можно вызвать службы WCF из глобального обработчика UnhandledException в Silverlight?

Question

Я пытаюсь сделать что-то вроде этого:

private void Application_UnhandledException(object sender, ApplicationUnhandledExceptionEventArgs e)
{
    try
    { 
        e.Handled = true;

        var errorMessage = BuildErrorMessage(e.ExceptionObject);
        var service = new MyService(Constants.MyBinding, Constants.MyServiceUri);
        service.LogErrorAsync(errorMessage);              
        // wait awhile for the channel to flush its buffers, hard abort if it takes too long
        //service.InnerChannel.Close(new TimeSpan(0, 0, 10));
    }
    finally
    {
        RestartSilverlightApp();
    }
}

Сначала это сработало - у меня есть записи в журнале, чтобы доказать это! - но не был надежным. Измененные вещи, и теперь я не могу заставить это работать вообще. Точки останова на серверном компоненте никогда не достигаются; Fiddler показывает, что клиент даже не отправляет HTTP-запрос по проводам. Вещи, которые я пробовал:

• Вставлен вызов функции Close (), даже с безумными длинными таймаутами. [по теории, приложение перезапускалось до того, как канал смог сделать свое дело] Результат: приложение всегда зависает, пока не истечет время ожидания. Я нашел это интересным - когда WCF ведет себя нормально, Close () возвращается почти мгновенно.
• Вставлен вызов service.InnerChannel.Open () в Application_Startup. [в случае, если что-то о нашем состоянии внутри обработчика исключений предотвращает переходы Созданный -> Открытый канал WCF]
• Сделал service членом класса App и инициализировал его в моем обработчике Application_Startup. [по теории о том, что вспомогательные классы, которые я использую для генерации прокси-серверов WCF, были разорваны / в каком-то плохом состоянии к тому времени, когда Silverlight размотал AppDomain до точки глобального обработчика исключений]
• Сделано Обслуживание Статическое. [по теории это был не тот экземпляр App, позволяющий service быть GC'd]
• Проверено, что service.State , service.EndPoint и любые другие открытые свойства, которые я мог быстро проверить в отладчике, были правильными непосредственно перед асинхронным вызовом.
• Проверено, что служба создает, асинхронный вызов и синхронные вызовы открытия / закрытия все происходили в основном потоке (UI), и что идентификатор потока был постоянным [без частичного / "скрытого" " Слезы перед вызовом моего обработчика.
• Перенес вызов в service.LogErrorAsync () за пределами Application_UnhandledException. [в случае, если что-то было неправильно настроено в другом месте] Это работало безупречно.

Я не специалист по жизненному циклу / архитектуре приложений Silverlight и не WCF. Идеи, которые я пропустил?

Answer 1

Итак Я не думаю, что ваш вопрос глупый , потому что я должен также пытаться регистрировать исключения во время любой точки жизненного цикла приложения silverlight. Мне интересно, однако, можно ли заменить WCF здесь с необработанным POST в стиле AJAX для службы, которая регистрирует ваше исключение. Вы можете привязать его к браузеру и выполнить вызов с помощью механизма JavaScript, а не использовать WebClient или что-то еще в экосистеме Silverlight.

Answer 2

Глупый вопрос ... Если ваше приложение только что упало, зачем пытаться сделать что-то столь же рискованное, как вызов веб-службы?

Стратегия, которую я обычно использую в таких случаях:
1. Зарегистрируйте необработанное исключение в IsoStore.
2. Перезапустите приложение.
3. когда приложение запускается, оно проверяет, не является ли журнал исключений IsoStore пустым. И если он не пуст - пытается отправить их на сервер регистратора.

Плюс, учитывая, что вы делаете асинхронный вызов и чем перезапускаете приложение, у вас, по сути, возникает условие гонки. что плохо Так что либо «холодный журнал» (мое первоначальное предложение), либо дождитесь, пока асинхронный вызов вернется / не удастся, а затем перезапустите приложение.