Разблокировать, генерируя файлы .pdb, почему?

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

ОТВЕТЫ

Ответ 1

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

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

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

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

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

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

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

Обратите внимание, однако, что конфигурации "Отладка" и "Отпуск" по умолчанию используют разные настройки для испускания отладочной информации. Вы захотите сохранить эту настройку. Параметр "Debug Info" установлен на "full" для сборки Debug, что означает, что в дополнение к файлу PDB в сборку встроена отладочная информация о символах. Вы также получаете символы, которые поддерживают интересные функции, такие как edit-and-continue. В режиме деблокирования выбирается опция "pdb-only", которая, как и звук, включает только файл PDB, не затрагивая содержимое сборки. Таким образом, это не так просто, как простое присутствие или отсутствие файлов PDB в вашем каталоге /bin. Но если вы используете опцию "pdb-only", присутствие файла PDB никоим образом не повлияет на производительность вашего кода во время выполнения.

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

Ответ 2

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

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

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

Ответ 3

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

Ответ 4

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

Ответ 5

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

Ответ 6

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

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

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

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

Ответ 7

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

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

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

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

Ответ 8

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

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

Ответ 9

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

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