Должен ли я компилировать сборки релизов с информацией об отладке как "полный" или "только pdb"?

Ответ 1

Я бы построил с помощью pdb-only. Вы не сможете подключить отладчик к выпущенному продукту, но если вы получите дамп сбоя, вы можете использовать Visual Studio или WinDBG для проверки следов стека и дампов памяти во время сбоя.

Если вы используете full, а не pdb-only, вы получите те же преимущества, за исключением того, что исполняемый файл может быть прикреплен непосредственно к отладчику. Вам нужно будет определить, насколько это разумно, учитывая ваш продукт и клиентов.

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

Если вы решите построить с помощью none, у вас не будет проблем при сбое в поле. Вы не сможете провести какое-либо послепроблемное рассмотрение аварии, что может серьезно затруднить вашу способность отслеживать проблему.

Заметка о производительности:

Оба Джон Роббинс и Эрик Липперт написали блог сообщения о знаке /debug, и оба они указывают, что этот параметр имеет нулевое воздействие производительности. Существует отдельный флаг /optimize, который определяет, должен ли компилятор выполнять оптимизации.

Ответ 2

Внимание MSDN документация для/debug-переключателя (в Visual Studio это Debug Info), похоже, устарела! Это то, что у него есть неверно

Если вы используете /debug: full, имейте в виду, что есть некоторые последствия для скорость и размер оптимизированного кода JIT и небольшое влияние на код качество с /debug: полно. Мы рекомендуем/отлаживать: pdbonly или PDB для генерирующий код выпуска.

Одно различие между /debug: pdbonly и /debug: full - это то, что с /debug: полный компилятор испускает DebuggableAttribute, который используется для сообщите компилятору JIT, что доступна отладочная информация.

Затем, что теперь верно?

• Только для Pdb. До .NET 2.0 он помог исследовать аварийные дампы выпущенного продукта (машины для клиентов). Но это не позволяло прикреплять отладчик. Это не относится к .NET 2.0. Он точно такой же, как Полный.
• Полный. Это помогает нам исследовать аварийные дампы, а также позволяет присоединить отладчик для выпуска сборки. Но, в отличие от MSDN, это не влияет на производительность (с .NET 2.0). Он работает точно так же, как только Pdb.

Если они точно такие же, почему у нас есть эти опции? Джон Роббинс (windows debugging god) узнал, что они существуют по историческим причинам.

В .NET 1.0 были различия, но в .NET 2.0 там нет. Похоже, что .NET 4.0 будет следовать одному и тому же шаблону. После двойная проверка с командой отладки CLR, нет никакой разницы в все.

Что контролирует, делает ли JITter сборку отладки/оптимизацией переключатель. <... >

Суть в том, что вы хотите построить свои сборки релизов с помощью /optimize + и любых/отладочных переключателей, чтобы вы могли отлаживать исходный код код.

то он продолжает это доказывать.

Теперь оптимизация является частью отдельного переключателя /optimize (в визуальной студии он называется Optimize code).

Короче говоря, независимо от настройки DebugInfo pdb-only или full, у нас будут одинаковые результаты. Рекомендация состоит в том, чтобы избежать Нет, поскольку это лишит вас возможности анализировать аварийные дампы от выпущенного продукта или прикреплять отладчик.

Ответ 3

Вам понадобится только PDB, но вы не захотите предоставить пользователям PDB файлы. Имея их для себя, хотя, наряду с вашими двоичными файлами, дает вам возможность загружать аварийные дампы в отладчик, такой как WinDbg, и видеть, где ваша программа действительно потерпела неудачу. Это может быть весьма полезно, когда ваш код сбой на компьютере, к которому у вас нет доступа.

Полная отладка добавляет к вашему коду атрибут [Отладка]. Это оказывает огромное влияние на скорость. Например, некоторые оптимизации цикла могут быть отключены, чтобы упростить простой шаг. Кроме того, он оказывает небольшое влияние на процесс JIT, поскольку он включает отслеживание.

Ответ 4

В процессе написания обработчика необработанных исключений трассировка стека включает номер строки, когда используется только pdb, иначе я просто получаю имя Sub/Function, когда я выбираю None.

Если я не распространю .pdb, я не получаю номер строки в трассировке стека даже с сборкой pdb.

Итак, я распространяю (развертывание XCOPY в локальной сети) pdb вместе с exe из моего приложения VB.