Я немного смущен тем, как использовать классы .NET Trace и Debug.
Зачем вам использовать Trace вместо Debug?
Trace.TraceError()
Trace.TraceInformation()
Trace.Assert()
Debug.WriteLine()
Debug.Assert()
Кроме того, я понимаю, что операторы отладки игнорируются, когда вы находитесь в режиме конфигурации выпуска, но если операторы трассировки применяются все время, как это влияет на производительность?
На самом простом уровне у них разные переключатели компиляции, т. е. Debug.WriteLine и т. д. переключается только в том случае, если у вас есть символ компиляции DEBUG (не характерный для релизных сборок), тогда как Trace.WriteLine обычно включается даже в релизные сборки.
Маршрут Trace имеет настраиваемых прослушивателей трассировки, которые можно подключить через конфигурацию; Debug обычно отправляется в отладчик как слушатель. Конечно, есть сторонние системы трассировки, которые предлагают гораздо большую гибкость.
Вы можете независимо включать и выключать с помощью переключателя компилятора, если вы перейдете на страницу сборки свойств вашего проекта, у вас есть несколько флажков.
Эмпирическое правило для меня заключается в том, что я использую отладку для фактической отладочной информации, т.е. значение переменной x в этот момент равно ... и т. д., и трассировку для отслеживания потока управления через мое приложение (больше похоже на спам).
Как вы сказали, вызовы трассировки выполняются только тогда, когда вы находитесь в режиме выпуска. Компиляция в режиме выпуска имеет некоторые преимущества в производительности, которые могут понадобиться в конечном приложении, и могут быть другие причины, по которым вы хотите включить режим выпуска. Однако могут быть случаи, когда вы хотите записать информацию на консоль трассировки, которую можно просмотреть с помощью таких приложений, как DbgView SysInternal. Обычно это сообщения, которые вы не обязательно хотите отправлять в вывод журнала или которые вы всегда хотите иметь доступными для целей отладки, даже если пользователь отключил ведение журнала.
Вы, конечно, не хотели бы отправлять много информации на консоль Trace, так как это приводит к снижению производительности, но некоторая важная информация может быть уместной.
Я предпочитал использовать Trace (с соответствующим TraceSwitch) для ведения журналов в средах релизов — быстрая настройка app.config может дать разные уровни ведения журналов без необходимости перекомпиляции (что в любом случае может решить проблему). ) или необходимость прикрепить отладчик. Особенно удобно для проблем, которые по какой-либо причине возникают только на компьютерах клиентов — я использовал это для успешного дампа выхода из класса FTP (еще в старые дни Framework 1.1), чтобы помочь диагностировать проблемы с сетевой передачей между двумя компаниями.
