Должен ли я скомпилировать сборки релизов с отладочной информацией как "полная" или "только для pdb"?
В Visual Studio 2010 для проекта C#, если вы идете в "Свойства проекта"> "Сборка"> "Дополнительно"> "Отладочная информация", у вас есть три варианта: ни один, ни полный, или только pdb. Основываясь на ответе на этот вопрос, я полагаю, что понимаю некоторые различия между full и pdb-only. Однако, что больше подходит для сборки релиза? Если я использую "полный", будут ли последствия для производительности? Если я буду использовать "pdb-only", будет ли сложнее отлаживать производственные проблемы?
В чем разница между "full" и "pdbonly"? https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/compiler-options/debug-compiler-option
4 ответа
Я бы построил с pdb-only, Вы не сможете прикрепить отладчик к выпущенному продукту, но если вы получите аварийный дамп, вы можете использовать Visual Studio или WinDBG для проверки следов стека и дампов памяти во время сбоя.
Если вы идете с full скорее, чем pdb-only вы получите те же преимущества, за исключением того, что исполняемый файл может быть подключен непосредственно к отладчику. Вам необходимо определить, является ли это обоснованным, учитывая ваш продукт и клиентов.
Обязательно сохраните файлы PDB где-нибудь, чтобы вы могли ссылаться на них при поступлении отчета о сбое. Если вы можете настроить сервер символов для хранения этих символов отладки, тем лучше.
Если вы решили построить с none вы не будете иметь права на спасение, когда произойдет сбой в поле. Вы не сможете провести какой-либо анализ после аварии факта, который может серьезно помешать вашей способности отследить проблему.
Примечание о производительности:
Джон Роббинс и Эрик Липперт написали в блоге сообщения о /debug флаг, и оба они указывают, что этот параметр не влияет на производительность. Есть отдельный /optimize флаг, который определяет, должен ли компилятор выполнять оптимизацию.
ВНИМАНИЕ! Документация MSDN для параметра /debug (в Visual Studio это информация об отладке) устарела! Это то, что есть, что неверно
Если вы используете /debug:full, имейте в виду, что это влияет на скорость и размер оптимизированного JIT кода и незначительно влияет на качество кода с помощью /debug:full. Мы рекомендуем /debug:pdbonly или нет PDB для генерации кода выпуска.
Одно из различий между /debug:pdbonly и /debug:full состоит в том, что с /debug:full компилятор выдает
DebuggableAttribute, который используется, чтобы сообщить компилятору JIT, что отладочная информация доступна.
Тогда что теперь верно?
- Только для Pdb - до.NET 2.0 он помогал исследовать аварийные дампы из выпущенного продукта (клиентские машины). Но это не позволило подключить отладчик. Это не тот случай с.NET 2.0. Это точно так же, как Full.
- Полный - Это помогает нам исследовать аварийные дампы, а также позволяет подключать отладчик для выпуска сборки. Но, в отличие от MSDN, он не влияет на производительность (начиная с.NET 2.0). Он делает то же самое, что и Pdb-only.
Если они точно такие же, почему у нас есть эти варианты? Джон Роббинс (Бог отладки окон) обнаружил, что они существуют по историческим причинам.
В.NET 1.0 были различия, а в.NET 2.0 - нет. Похоже, что.NET 4.0 будет следовать той же схеме. После двойной проверки с командой отладки CLR разницы нет вообще.
То, что JITter выполняет отладочную сборку, контролирует ключ / optimize. <...>
Суть в том, что вы хотите собирать сборки релизов с помощью / optimize + и любого из ключей /debug, чтобы вы могли отлаживать их с помощью исходного кода.
затем он продолжает доказывать это.
Теперь оптимизация является частью отдельного переключателя /optimize (в визуальной студии это называется Optimize code).
Короче говоря, независимо от того, как DebugInfo установит pdb-only или full, мы получим одинаковые результаты. Рекомендуется избегать None, поскольку это лишит вас возможности анализировать аварийные дампы из выпущенного продукта или подключать отладчик.
Вам понадобится только PDB, но вы не захотите передавать файлы PDB пользователям. Однако, имея их для себя, вместе с вашими двоичными файлами, вы можете загружать аварийные дампы в отладчик, такой как WinDbg, и видеть, где ваша программа действительно потерпела неудачу. Это может быть довольно полезно, когда ваш код падает на машине, к которой у вас нет доступа.
Полная отладка добавляет атрибут [Debuggable] в ваш код. Это оказывает огромное влияние на скорость. Например, некоторые оптимизации цикла могут быть отключены, чтобы упростить один шаг. Кроме того, он оказывает небольшое влияние на процесс JIT, так как включает отслеживание.
Я нахожусь в процессе написания необработанного обработчика исключений, и трассировка стека включает номер строки, когда используется только pdb, в противном случае я просто получаю имя Sub/Function, когда выбираю None.
Если я не распространю.pdb, я не получу номер строки в трассировке стека даже при сборке только для pdb.
Итак, я распространяю (развертывание XCOPY в локальной сети) pdb вместе с exe из моего приложения VB.