Выпуск, генерирующий файлы .pdb, почему?

265

Почему Visual Studio 2005 генерирует .pdbфайлы при компиляции в выпуске? Я не буду отлаживать сборку релиза, так почему они генерируются?

m.edmondson
источник
18
Зачем генерировать pdb в релизе? Поэтому, когда отчет о сбое приходит из дикой местности, у вас есть информация для его отладки. Другое значение состоит в том, что клиенты могут отлаживать его, когда первоначальный автор этого не делает.
Ян Бойд
@IanBoyd: Второе предложение этого комментария подразумевает, что вы развернули PDB. Это в подавляющем большинстве случаев нежелательно.
2
3
@ IInspectable Или желательно
Ян Бойд
@IanBoyd: подавляющее большинство случаев не включает развертывание ОС. Кроме того, эти PDB не содержат частных символов, которые включены по умолчанию, когда вы генерируете PDB.
IInspectable
@IInspectable С другой стороны, выпустив PBDs является желательным. В идеале, да, каждый писал бы код, скомпилированный в IL, чтобы мы сами могли получить информацию о символах. Но компиляторы нативного кода все еще не имеют простого способа поддержки отладки в полевых условиях.
Ян Бойд

Ответы:

417

Потому что без файлов PDB было бы невозможно отладить сборку "Release" с помощью чего-либо, кроме отладки на уровне адресов. Оптимизация действительно влияет на ваш код, поэтому очень сложно найти виновника, если что-то пойдет не так (скажем, исключение выдается). Даже установка точек останова чрезвычайно трудна, потому что строки исходного кода не могут быть сопоставлены один к одному (или даже в том же порядке, что и) сгенерированного кода сборки. Файлы PDB помогают вам и отладчику, значительно облегчая отладку после вскрытия.

Вы утверждаете, что если ваше программное обеспечение готово к выпуску, то к тому времени вы должны были выполнить всю отладку. Хотя это, безусловно, правда, есть несколько важных моментов, о которых следует помнить:

  1. Вам также следует протестировать и отладить свое приложение (перед его выпуском), используя сборку «Release». Это связано с тем, что включение оптимизаций (по умолчанию они отключены в конфигурации «Отладка») может иногда приводить к появлению незаметных ошибок, которые иначе не удалось бы обнаружить. Когда вы делаете эту отладку, вам понадобятся символы PDB.

  2. Клиенты часто сообщают о крайних случаях и ошибках, которые возникают только в «идеальных» условиях. Это вещи, которые практически невозможно воспроизвести в лаборатории, потому что они полагаются на какую-то дурацкую конфигурацию компьютера этого пользователя. Если они особенно полезные клиенты, они сообщат об исключении, которое было сгенерировано, и предоставят вам трассировку стека. Или они даже позволят вам одолжить их машину для удаленной отладки программного обеспечения. В любом из этих случаев вам понадобятся файлы PDB.

  3. Профилирование всегда должно выполняться в сборках "Release" с включенной оптимизацией. И снова, файлы PDB пригодятся, потому что они позволяют отображать профилированные инструкции по сборке обратно в исходный код, который вы фактически написали.

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

Если вы действительно хотите отключить их, это всегда вариант. В окне свойств вашего проекта установите для параметра «Информация об отладке» значение «none» для любой конфигурации, которую вы хотите изменить.

Есть ли к сведению, однако, что конфигурации «Debug» и «Release» сделать по умолчанию использует различные настройки для излучения отладочной информации. Вы хотите сохранить эту настройку. Параметр «Информация об отладке» установлен на «полный» для сборки отладки, что означает, что в дополнение к файлу PDB информация об символах отладки встроена в сборку. Вы также получаете символы, которые поддерживают интересные функции, такие как редактирование и продолжение. В режиме Release выбирается опция «только для pdb», которая, как это звучит, включает в себя только файл PDB, не затрагивая содержимое сборки. Так что это не так просто, как простое присутствие или отсутствие файлов PDB в вашем /binкаталоге. Но при условии, что вы используете опцию «pdb-only», файл PDB '

* Как отмечает Марк Шерман в комментарии , пока ваш исходный код не изменился (или вы можете получить исходный код из системы контроля версий), вы можете перестроить его и сгенерировать соответствующий файл PDB. По крайней мере, обычно. В большинстве случаев это работает хорошо, но компилятору не гарантируется, что он генерирует идентичные двоичные файлы каждый раз, когда вы компилируете один и тот же код , поэтому могут быть небольшие различия. Хуже того, если вы в то же время произвели какие-либо обновления в своей цепочке инструментов (например, применили пакет обновления для Visual Studio), вероятность совпадения PDB еще меньше. Чтобы гарантировать надежное поколение ex postfactoPDB-файлы, вам нужно будет заархивировать не только исходный код в вашей системе контроля версий, но и двоичные файлы для всей цепочки инструментов сборки, чтобы можно было точно воссоздать конфигурацию среды сборки. Само собой разумеется, что гораздо проще просто создавать и архивировать файлы PDB.

Коди Грей
источник
19
«Вы не можете сгенерировать файлы PDB после компиляции». - Если ваш исходный код не изменился, вы можете перестроить его для создания пригодной для использования PDB. По умолчанию windbg не загружает этот PDB, но вы можете принудительно загрузить его, указав параметр / i следующим образом .reload /i foo.dll. Это загрузит foo.pdb, даже если foo.pdb был создан после выпуска foo.dll.
Марк Шерман
Я заметил, что у каждого нового компилятора разный хэш-дайджест, поэтому есть небольшие различия с каждой сборкой даже в одной и той же среде. Могут ли адреса для PDB не изменяться с разницей, следовательно, необходимо удерживать PDB от этой сборки? Просто выдвину это как идею, поскольку я не совсем понимаю, как работают PDB или почему хеши меняются между сборками.
thebunnyrules
1
@ the В сноске я ссылался на статью, объясняющую, что «компилятор C # по своему дизайну никогда не генерирует один и тот же двоичный файл дважды. Компилятор C # внедряет только что сгенерированный GUID в каждую сборку каждый раз, когда вы его запускаете, тем самым гарантируя, что нет двух сборок когда-либо одинаково ". Это объясняет, почему у него другой хэш, и, следовательно, другой файл PDB. Это можно исправить с помощью шестнадцатеричного редактора, но не удобно для пользователя. А также за пределами этого ответа.
Cody Серый
3
В Roslyn появилась новая функция, называемая детерминированными сборками. «/ Детерминированный флаг заставляет компилятор испускать одинаковые EXE / DLL, байт за байт, при наличии одинаковых входных данных». Это означает, что проект, изначально скомпилированный с этим флагом, может быть перекомпилирован в точно такой же двоичный файл, если код, который вы компилируете, одинаков. Более подробное объяснение можно найти в детерминированных сборках в Roslyn
K Smith
92

PDB может быть сгенерирован Releaseкак для, так и для Debug. Это установлено в (в VS2010, но в VS2005 должно быть аналогичным):

Проект → Свойства → Сборка → Дополнительно → Отладочная информация

Просто измените это на None.

Aliostad
источник
2
Но зачем ты это делаешь? Если ваше программное обеспечение готово к выпуску, то к тому времени вы должны были выполнить всю отладку
m.edmondson
4
Потому что вы можете отлаживать производственные проблемы. Однажды нам пришлось это сделать.
Алиостад
21
Преимущество заголовка PDB для производственного кода заключается в том, что .NET будет использовать эти файлы при создании исключений. Он генерирует трассировки стека с именами файлов и номерами строк, что часто очень удобно!
Стивен
6
@ m.edmondson: Да, это правильно. Вы все еще будете проинформированы , что выброшенное исключение было (как FileNotFoundException), но вы не сможете увидеть трассировки стека. Это делает очень трудным точно определить, какая именно строка кода вызвала исключение.
Коди Грей
2
@ m.edmondson Просто добавьте, если вы ищете инструмент для удаленной отладки одной из проблем в ваших производственных блоках, тогда Windows SDK поставляется с очень известным инструментом WinDbg, который поддерживает удаленную отладку. Пожалуйста, посмотрите на ссылку ниже. Надеюсь это поможет! msdn.microsoft.com/en-in/library/windows/hardware/...
RBT
8

Без файлов .pdb практически невозможно выполнить рабочий код; Вы должны полагаться на другие инструменты, которые могут быть дорогостоящими и длительными. Я понимаю, что вы можете использовать трассировку или, например, windbg, но это действительно зависит от того, чего вы хотите достичь. В определенных сценариях вы просто хотите пройтись по удаленному коду (без ошибок или исключений), используя производственные данные для наблюдения за конкретным поведением, и именно здесь пригодятся файлы .pdb. Без них запуск отладчика для этого кода невозможен.

user1714880
источник
7

Почему вы так уверены, что не будете отлаживать сборки релизов? Иногда (надеюсь, редко, но бывает) вы можете получить отчет о дефекте от клиента, который по какой-то причине не воспроизводится в отладочной версии (разные временные характеристики, небольшое другое поведение или что-то еще). Если эта проблема кажется воспроизводимой в сборке выпуска, вы будете рады иметь соответствующий pdb.

jdehaan
источник
5
@ m.edmondson Получите доступ к удаленному компьютеру, используя RDP, Webex и т. д., и установите там windbg. Установите свой путь символов и бац, ты золотой!
Марк Шерман
Ссылка на более подробное руководство была бы более полезной. Эта однострочная инструкция может привести людей (таких как я) на неправильный путь. Например, большинство разработчиков .NET ничего не знают о Windbg.
nuzzolilo
1
@ m.edmondson - некоторые выпуски Visual Studio имеют возможность выполнять удаленную отладку. Из меню отладки вы «подключаетесь к процессу» на удаленной машине.
Мэтью
Это хорошая идея для удаленной отладки экземпляра производственного приложения? Не прервет ли это параллельное выполнение потоков и заставит их работать последовательно при отладке?
Каве Хаджари
4

Кроме того, вы можете использовать аварийные дампы для отладки вашего программного обеспечения. Клиент отправляет его вам, а затем вы можете использовать его для определения точной версии вашего источника - и Visual Studio даже извлечет правильный набор символов отладки (и источника, если вы настроены правильно), используя аварийный дамп. См. Документацию Microsoft по символическим магазинам .

rlranft
источник
2

Файл .PDB - это короткое имя «База данных программы». Он содержит информацию о точке отладки для отладчика и используемых ресурсах или ссылки. Он генерируется при сборке в режиме отладки. Это позволяет приложению отлаживать во время выполнения.

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

Хорошая статья о файле pdb.

http://www.codeproject.com/Articles/37456/How-To-Inspect-the-Content-of-a-Program-Database-P

Ajay2707
источник
1
«Нет необходимости в этом файле при выпуске или развертывании», за исключением случаев, когда кто-то испытывает сбой в этой выпущенной версии, и отчет о сбое, который вы получаете от них, не содержит полезной трассировки стека ... тогда вы захотите включить его после все.
Nyerguds
Не правда. Без файлов .pdb вы получите полную трассировку стека, но без имен исходных файлов. Вы можете восстановить его на месте после получения отчета о сбое. Если вы заботитесь о своих интеллектуальных правах и запутываете источники, вам нужно сохранять файлы .pdb, а не развертывать их.
TOP KEK
1

В многопроектном решении вы обычно хотите иметь одну конфигурацию, которая вообще не генерирует файлы PDB или XML. Вместо того, чтобы изменять Debug Infoсвойство каждого проекта на none, я подумал, что было бы более целесообразно добавить событие после сборки, которое работает только в определенной конфигурации.

К сожалению, Visual Studio не позволяет указывать разные события после сборки для разных конфигураций. Поэтому я решил сделать это вручную, отредактировав csprojфайл запуска проекта и добавив следующее (вместо любого существующего PostBuildEventтега):

  <PropertyGroup Condition="'$(Configuration)' == 'Publish'">
    <PostBuildEvent>
        del *.pdb
        del *.xml
    </PostBuildEvent>
  </PropertyGroup>

К сожалению, это приведет к тому, что текстовое поле события после сборки станет пустым, а помещение чего-либо может привести к непредсказуемым результатам.

GregRos
источник
4
Это удалит ВСЕ *.xmlфайлы, будьте осторожны с этим.
Мариуш Джамро
0

Файлы символов отладки ( .pdb) и файлы XML doc ( .xml) составляют большой процент от общего размера и не должны входить в стандартный пакет развертывания. Но должна быть возможность доступа к ним в случае необходимости.

Один из возможных подходов: в конце процесса сборки TFS переместите их в отдельный артефакт.

Марк Йоханес
источник
-1

На самом деле без PDB-файлов и символической информации, которую они имеют, было бы невозможно создать успешный отчет о сбое (файлы дампа памяти), и у Microsoft не было бы полной картины того, что вызвало проблему.

И поэтому наличие PDB улучшает отчеты о сбоях.

прости
источник
Но что именно будет отсутствовать без файлов .pdb?
TOP KEK
Вы не можете генерировать файлы PDB после компиляции. Таким образом, каждая версия программного обеспечения major.minor [.build [.revision]] должна была быть сохранена в Microsoft, чтобы правильно понять, что произошло, но это еще не все.
Прости
Компилятору не гарантируется создание одинаковых двоичных файлов каждый раз, когда вы компилируете один и тот же код.
Прости
Вопрос заключался в том, что будет отсутствовать в отчетах о сбоях и как это отразится на сообщениях о сбоях. Файлы .NET pdb содержат только имена частных переменных и имена исходных файлов. Все остальное (имена методов, подписи и т. Д.) Будет находиться в трассировке стека из информации метаданных.
TOP KEK
Файлы PDB также не содержат непубличных данных: github.com/microsoft/microsoft-pdb .
Прости