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


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

8 233

8 ответов:

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

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

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

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

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

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

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

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

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

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

ProjectPropertiesBuildAdvancedDebug Info

просто измените его на 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 tag):

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

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

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

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