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

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

Потому что без файлов 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.}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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