Поскольку без файлов PDB было бы невозможно отладить сборку "Release" с помощью чего-либо, кроме отладки на уровне адресов. Оптимизации действительно сильно влияют на ваш код, что делает его очень трудным для поиска виновник, если что-то пойдет не так (скажем, исключение выдается). Даже установка точек останова чрезвычайно трудна, потому что строки исходного кода не могут быть сопоставлены один к одному (или даже в том же порядке, что и) сгенерированного кода сборки. Файлы PDB помогают вам и отладчику значительно упростить отладку после вскрытия.
Вы утверждаете, что если ваше программное обеспечение готово к выпуску, к тому времени вы должны были выполнить всю отладку. Хотя это, безусловно, так, есть несколько важных моментов, о которых следует помнить:
Вы должны также протестировать и отладить свое приложение (перед его выпуском), используя сборку "Release". Это связано с тем, что включение оптимизаций (по умолчанию они отключены в конфигурации «Отладка») может иногда приводить к появлению незаметных ошибок, которые иначе не удалось бы обнаружить. Когда вы делаете эту отладку, вам понадобятся символы PDB.
Клиенты часто сообщают о крайних случаях и ошибках, которые возникают только в «идеальных» условиях. Это вещи, которые практически невозможно воспроизвести в лаборатории, потому что они полагаются на какую-то дурацкую конфигурацию компьютера этого пользователя. Если они особенно полезные клиенты, они сообщат об исключении, которое было сгенерировано, и предоставят вам трассировку стека. Или они даже позволят вам одолжить их машину для удаленной отладки программного обеспечения. В любом из этих случаев вам понадобятся файлы PDB.
Профилирование должно всегда выполняться в сборках "Release" с включенной оптимизацией. И снова, файлы PDB пригодятся, потому что они позволяют отображать профилированные инструкции по сборке обратно в исходный код, который вы на самом деле написали.
Вы не можете вернуться и сгенерировать файлы PDB после компиляции. * Если вы не создадите их во время сборки, вы упустили свою возможность. Ничто не повредит их созданию. Если вы не хотите распространять их, вы можете просто опустить их из своих двоичных файлов. Но если позже вы решите, что хотите их, вам не повезло. Лучше всегда генерировать их и архивировать копии на тот случай, если они вам понадобятся.
Если вы действительно хотите отключить их, это всегда вариант. В окне свойств вашего проекта установите для параметра «Информация об отладке» значение «none» для любой конфигурации, которую вы хотите изменить.
Обратите внимание, однако, что конфигурации «Debug» и «Release» do по умолчанию используют разные параметры для выдачи отладочной информации. Вы хотите сохранить эту настройку. Параметр «Информация отладки» установлен на «полный» для сборки отладки, что означает, что в дополнение к файлу PDB информация об символах отладки встроена в сборку. Вы также получаете символы, которые поддерживают интересные функции, такие как редактирование и продолжение. В режиме Release выбран параметр «только для pdb», который, как это звучит, включает в себя только файл PDB, не затрагивая содержимое сборки. Так что это не так просто, как простое присутствие или отсутствие файлов PDB в вашем каталоге /bin. Но при условии, что вы используете опцию «pdb-only», наличие файла PDB никоим образом не повлияет на производительность вашего кода во время выполнения.
* Как Марк Шерман указывает в комментарии , если ваш исходный код не изменился (или вы можете получить исходный код из системы контроля версий).система), вы можете восстановить его и создать соответствующий файл PDB.По крайней мере, обычно.В большинстве случаев это работает хорошо, но компилятору не гарантируется генерирование идентичных двоичных файлов каждый раз, когда вы компилируете один и тот же код , поэтому может иметь небольшие различия.Хуже того, если вы сделали какие-либо обновления в своей цепочке инструментов (например, применили пакет обновления для Visual Studio), вероятность того, что PDB будут совпадать, еще меньше.Чтобы гарантировать надежное создание файлов ex postfacto PDB, вам потребуется архивировать не только исходный код в вашей системе управления версиями, но и двоичные файлы для всего набора инструментов сборки, чтобы обеспечить точное воссозданиеконфигурация вашей среды сборки.Само собой разумеется, что гораздо проще просто создавать и архивировать файлы PDB.