Во-первых, я сожалею о том, что должно быть дублирующимся сообщением. Похоже, что я не могу сузить свой поиск на SO и google, чтобы найти то, что я ищу.
В настоящее время я работаю в магазине, где им нравится их исключение. Когда скомпилированное приложение переходит на тестирование, большая боль пытается получить сведения об исключении (трассировка сообщений и стека). Windows показывает это знакомое поле, в котором отсутствуют какие-либо детали, которые когда-либо были.
После того, как мы провели почти час, выяснив, что тестовая коробка имеет неправильную версию хрустальных отчетов, я добавил, что этот простой код всегда известен.
static void Main(string[] arg)
{
AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);
Application.ThreadException += new System.Threading.ThreadExceptionEventHandler(Application_ThreadException);
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run( ... );
}
static void Application_ThreadException(object sender, System.Threading.ThreadExceptionEventArgs e)
{
MessageBox.Show(e.Exception.ToString());
}
static void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
{
MessageBox.Show((e.ExceptionObject as Exception).ToString());
}
Выполняется эта работа, но мне не разрешено ее проверять. Есть ли способ в app.config или через параметр реестра, чтобы CLR отображал или записывала данные о деталях для скомпилированного приложения .net?
Заранее благодарим за помощь.
просто используйте log4net, если вы хотите настроить вывод журнала.
Можете ли вы использовать корпоративную библиотеку? Существуют блоки обработки исключений и протоколирования, которые могут быть вам полезны. Вы можете настроить блок обработки исключений на уведомлять и восстанавливать исходное исключение и записывать данные с помощью регистрационного блока. Это может быть немного крутой холм, чтобы подняться, чтобы справиться с ним, но я думаю, что это будет стоить того, в конце концов.
Похоже, вам не хватает try-catch
верхнего уровня в вашем методе Main()
. См. один из моих ответов для примера.
И я бы не использовал MessageBox
, а один единственный статический метод, который регистрирует проблему так, как вы хотите/нуждаетесь, а затем показывает общую "Неожиданную фатальную ошибку. [Bla bla bla]" сообщение и убивает работающий процесс в Ok.
Решение Shimmy удобно, если вы знаете, как закодировать в VB.NET.
Затем вы можете перейти рекурсивно в ex.InnerException.InnerException.
... и так далее... для создания полного сообщения
(1) если ex.Message
не null
или Empty
, покажите его.
(2) если ex.InnerException
не null
показывает ex.InnerException.Message
.
У вас есть возможность обернуть код обработки отладки в условных символах компиляции. Это позволит вам предоставить подробный журнал, который вы хотите для целей тестирования, но это не будет доступно конечным пользователям в версиях сборки приложения.
Я использую WPF, поэтому здесь все пузырьки с необработанными исключениями могут быть полезны для ваших нужд:
Private Sub Application_DispatcherUnhandledException(ByVal sender As Object, ByVal e As System.Windows.Threading.DispatcherUnhandledExceptionEventArgs) Handles Me.DispatcherUnhandledException
'TODO: Log error'
Dim sb As New System.Text.StringBuilder(e.Exception.Message & vbCrLf)
Dim ex = e.Exception.InnerException
While ex IsNot Nothing
sb.AppendLine("______________ inner exception: ______________")
sb.AppendLine(ex.Message)
sb.AppendLine(vbCrLf)
ex = ex.InnerException
End While
If MessageBox.Show(sb.ToString, "Exception caught", MessageBoxButton.OKCancel) = MessageBoxResult.Cancel Then Stop
e.Handled = True
End Sub
Примите мои извинения. У меня не было времени переписать его, я просто скопировал свой оригинальный код, я уверен, что он по-прежнему полезен.
Спасибо