Visual studio убрать pdb
Обновлено: 06.07.2024
Как Visual Studio не создает файлы .vshost.exe и .pdb
При использовании Visual Studio для компиляции проекта по умолчанию файлы с расширениями «.vshost.exe» и «.pdb» будут созданы, даже если выбрано «Выпуск».
Сначала объясните роль каждого файла:
.pdb файл:
Файл базы данных программы. По умолчанию PDB Debug заполнен, что сохраняет отладочную информацию и информацию о состоянии проекта, утверждения, проверку стека и другие коды, а также может постепенно связывать конфигурацию отладки программы.
По умолчанию параметр Release указывает pdb-only для PDB, что сохраняет ошибку в программе и ее местонахождение.
Файл .vshost.exe:
Файл хост-процесса (хост-процесс VS) - это функция Visual Studio 2005, в основном для повышения производительности отладки. Лучше всего удалить при выпуске.
.vshost.exe.manifest файл:
Это XML-файл с суффиксом .manifest. Он используется для организации и описания изолированных приложений и параллельных компонентов, а также для привязки и активации классов, интерфейсов и библиотек COM. В прошлом эта информация всегда хранилась в реестре. .
Манифесты также формулируют файлы и классы Windows, составляющие сборку, и их лучше всего удалить во время выпуска.
2. Способы предотвращения создания этих файлов:
Способ не создавать файл .vshost.exe
Как показано на рисунке, откройте вкладку отладки в свойствах проекта, выберите композицию как «Release», снимите флажок «Visual Studio Hosting Process valid» и сохраните.
Способ не создавать файл .pdb
Как показано на рисунке, откройте вкладку сборки свойств проекта, выберите «Выпуск» для композиции и откройте «Подробные настройки». Измените «Debug Information» в «Output» с «pdb only» на «none» и сохраните.
каждый раз, когда я запускаю новую часть программного обеспечения, я должен войти в конфигурацию и отключить генерацию файлов pdb и процесс размещения Visual Studio для сборки выпуска. Есть ли способ сказать Visual Studio (2008 конкретно), что я хочу сделать это для всех проектов в остальное время?
вы должны иметь возможность обрабатывать проблему PDB аналогичным образом, но, как я уже сказал, Я не рекомендую отключать их, поэтому я оставлю это как упражнение :)
это относится к VS2008, но я предполагаю, что другие издания имеют аналогичную схему. Фактически, VS2010 использует тот же подход, но, очевидно, номер версии в каталоге-10.0 вместо 9.0.
в VS 2010 вы найдете свойство проекта для управления .генерация pdb в разделе свойства проекта - > сборка - > дополнительно. - >Отладочная Информация
установите значение " нет "для подавления.pdb поколения.
Почему бы не добавить после построения шаг, который удаляет эти файлы, которые вы не хотите. Хм, это еще один шаг, а не то, что вы хотели : - (
Как насчет написания небольшого вспомогательного приложения, которое выполняет цикл FindFirstFile и findnextfile, ища файлы PDB и shost в ваших каталогах выпуска. Когда он находит их, он их удаляет. Или, еще лучше, перемещает их в архив - это позволяет удалить их из проблем с выпуском упаковки, но все же сохранить файлы в случае необходимости для анализа ошибок.
плюс, потому что его помощник приложение, которое вы можете просто запустить его один раз в рамках предварительной передачи, чтобы освободить персонал.
мы используем эту технику для многих вещей:
- обеспечение DLL в актуальном состоянии (в основном интеллектуальное обновление для всего дерева сборки)
- очистка VC строит лучше, чем " пакетная сборка "(удаление некоторых из тех файлов, которые могут привести к сбою Visual Studio)
- архивирование определенных определенным образом (похоже на то, что я предложил для вас)
- etc
Я с Брайаном - вы должны сохранить эти файлы. Если вам нужно отладить любую ошибку или сбой, вам понадобятся эти файлы.
Я использую библиотеку из CGAL, которая на этапе компоновки моего кода компиляции выдает множество предупреждений о компоновке в этой форме:
Как отключить это предупреждение компоновщика в Visual C ++ / Studio 2008?
Добавьте следующее в качестве дополнительной опции компоновщика:
Это в Properties-> Linker-> Command Line
Я не думаю, что / игнорировать существует. Ошибки по-прежнему перечислены, а / ignore не задокументирован в MSDN. Я пытаюсь отключить 4075 для «предупреждения LNK4075: игнорирование '/ EDITANDCONTINUE' из-за спецификации '/ INCREMENTAL: NO'». Работает на VS 2015 (проект использует набор инструментов VS2013, не уверен, что это имеет значение)Как сообщается, с VS 2013 это предупреждение можно отключить. См. Комментарий @Mark Ransom.
Оригинальный ответ
Вы не можете отключить это конкретное предупреждение.
По словам Джеффа Чаппелла, предупреждение 4099 обрабатывается так, как будто его слишком важно игнорировать, даже при использовании вместе с / wx (который будет рассматривать предупреждения как ошибки и игнорировать указанное предупреждение в других ситуациях)
Вот соответствующий текст из ссылки:
Он не говорит, что «предупреждение 4099 слишком важно, чтобы его игнорировать»; он делает это из того факта, что его нельзя выключить. (Отмечено здесь, поскольку по этой ссылке нет дополнительной информации.) Этот ответ старый , отключение предупреждения 4099 отлично работало для меня на VS2017. Из комментариев здесь видно, что его можно отключить, вероятно, начиная с VS2013.(Для записи и до того, как поток исчезнет на форумах msdn) Вы не можете отключить предупреждение (по крайней мере, в VS2010), потому что оно находится в списке предупреждений, которые нельзя отключить (поэтому / wd4099 не будет работать) , но вместо этого вы можете сделать патч link.exe (обычно C: \ Program Files (x86) \ Microsoft Visual Studio 10.0 \ VC \ bin \ link.exe), чтобы удалить его из указанного списка. Я знаю, это похоже на отбойный молоток. Хотя это работает.
Например, если вы хотите удалить предупреждение для 4099, откройте link.exe с помощью шестнадцатеричного редактора, перейдите к строке 15A0, которая читает 03 10 (с прямым порядком байтов для 4099), и замените ее на FF 00 (которого не существует).
Вы должны искать последовательность F8 0F 00 00-03 10 00 00-09 10 00 00 (4088, 4099, 4105 как 32-битные двойные слова с прямым порядком байтов). То же самое и в amd64 / link.exe.Для пользы других я решил включить то, что сделал.
Поскольку вы не можете заставить Visual Studio (в моем случае 2010) игнорировать предупреждения LNK4204, мой подход заключался в том, чтобы дать ему то, что он хотел: файлы pdb. Поскольку в моем случае я использовал библиотеки с открытым исходным кодом, у меня уже есть код, создающий файлы pdb.
НО, по умолчанию все файлы PDF называются одинаково: в моем случае vc100.pdb. Поскольку вам нужен .pdb для каждого .lib, это создает проблему, особенно если вы используете что-то вроде ImageMagik, которое создает около 20 статических .lib-файлов. У вас не может быть 20 файлов lib в одном каталоге (на который компоновщик вашего приложения ссылается для компоновки в библиотеках) и все 20 файлов .pdb называться одинаково.
Мое решение заключалось в том, чтобы перестроить мои файлы статической библиотеки и настроить VS2010 на имя файла .pdb по отношению к ПРОЕКТУ. Таким образом, каждый .lib получает одноименный .pdb, и вы можете поместить все LIB и PDB в один каталог для использования в вашем проекте.
Итак, для конфигурации «Отладка» я отредактировал:
Свойства-> Свойства конфигурации -> C / C ++ -> Выходные файлы -> Имя файла базы данных программы из
$ (IntDir) $ VC (PlatformToolsetVersion) .pdb
быть следующим значением:
$ (OutDir) $ VC (PlatformToolsetVersion) D $ (ProjectName) .pdb
Теперь, а не где-то в промежуточном каталоге, файлы .pdb записываются в выходной каталог, где также записываются файлы .lib, И, что наиболее важно, они называются с суффиксом имени проекта D + . Это означает, что каждый проект библиотеки создает файл .lib проекта и отдельный файл .pdb проекта.
Теперь я могу скопировать все мои файлы .lib выпуска, мои файлы .lib отладки и файлы .pdb отладки в одно место в моей системе разработки, а проект, который использует эту стороннюю библиотеку в режиме отладки, имеет pdb файлы, необходимые в режиме отладки.
Обычно первый этап происходит на вашем CI сервере, а второй шаг происходит позже, во время работы самого приложения. Когда же мы работаем локально в Visual Studio, то она все эти шаги выполняет перед запуском приложения из меню Debug.
Шаг первый. Компиляция приложения
Ваш код превращается в Common Intermediate Language (CIL), который уже может быть выполнен в любом окружении, которое поддерживает CIL. Обратите внимание, что собранная сборка не является читаемым текстом IL, а фактически метаданными и байтовым кодом в виде двоичных данных.
На данном шаге будет выполнена некоторая оптимизация кода (будет описано дальше).
Шаг второй. JIT компилятор
JIT компилятор конвертирует IL код в инструкции процессора, которые можно выполнить на вашей машине. Однако не вся компиляция происходит заранее — в нормальном режиме, код компилируется, только тогда когда его вызывают в первый раз, после чего он кэшируется.
Основная часть оптимизации кода будет проведена на этом шаге.
Что такое оптимизация кода в одном предложении?
Почему мы заинтересованы в оптимизации в этой статье?
На обоих этапах компиляции ваш код будет оптимизирован компиляторами. Одно из ключевых различий между конфигурациями сборки Debug и Release заключается в том, отключены ли оптимизации или нет, поэтому нам нужно понять последствия данных оптимизации.
Инструкция nop в IL
Команда nop имеет ряд применений при программировании на низком уровне, например, для включения небольших предсказуемых задержек или инструкции по перезаписи, которые вы хотите удалить. В IL коде данные конструкции помогают при использовании точек останова (breakpoints) для того чтобы они вели себя предсказуемо.
Если мы посмотрим на IL код, который сгенерирован с отключенными оптимизациями:
Эта инструкция мапиться с фигурной скобкой, для того чтобы мы могли поставить на нее точку остановки:
Даная инструкция была бы удалена если у нас включены оптимизации, что повлияло бы на отладку приложения.
Оптимизация JIT компилятора
Несмотря на то, что он быстро выполняет свою работу во время выполнения, компилятор JIT также выполняет множество оптимизаций. О его внутренних деталях мало информации. Даже во время работы вашего приложения он производит профилирование и, возможно, перекомпилирование кода для повышения производительности.
Хорошие примеры оптимизации с помощью JIT компилятора можете посмотреть здесь.
Я рассмотрю один пример, чтобы проиллюстрировать влияние оптимизации на отладку.
Встраивание методов
Предположим, что у меня есть:
Компилятор JIT, скорее всего, выполнит встроенное расширение. Он заменит вызов метода Add() телом данного метода:
Конфигурации сборки по умолчанию
Довольно просто — релиз полностью оптимизирован, отладка совсем отсутствует, что, как вы сейчас знаете, имеет фундаментальное значение для того, насколько легко отлаживать ваш код. Но это просто поверхностное представление о возможностях аргументов отладки и оптимизации.
Внутренности аргументов оптимизации и отладки
Я попытался продемонстрировать данные аргументы из кода Roslyn и mscorlib. Теперь мы имеем следующие классы:
Синие элементы обозначаю аргументы командной строки, а зеленые их представление в коде.
Перечисление OptimizationLevel
OptimizationLevel.Release включает все оптимизации (DebuggableAttribute.DebuggingModes = ( 01 00 02 00 00 00 00 00 )) что в свою очередь соответсвует DebuggingModes.IgnoreSymbolStoreSequencePoints
При этом уровне оптимизации точки останова могут быть оптимизированы. Что приведет к тому что мы не сможем их поставить и остановиться.
Типы IL
Типы IL кода описаны в классе ILEmitStyle.
- ILEmitStyle.Debug — нету оптимизация IL в дополнение к добавлению nop инструкций для сопоставления точекостановки с IL.
- LEmitStyle.Release — полная оптимизация.
- ILEmitStyle.DebugFriendlyRelease — выполняет только те оптимизации, которые не помешаю отладке приложения.
Следующий кусок кода продемонстрирует все это наглядно.
Комментарий в исходном файле Optimizer.cs гласит, что они не опускают никаких определенных пользователем локальных переменных (примеры на 28 строчке) и не переносят значения в стек между операторами.
Я рад, что прочитал это, так как я был немного разочарован своими собственными экспериментами в ildasm с debug +, поскольку все, что я видел, это сохранение локальных переменных.
Нет намеренной «деоптимизации», например, добавления команд nop.
Разница между debug, debug:full и debug:pdbonly.
На самом деле разницы никакой нету, что подтверждает официальная документация:
Результат остается одним и тем же — pdb файл создается.
Подгланув в CSharpCommandLineParser можем убедиться в этом. И для того чтобы проверить это, мне удалось отладить код с помощью WinDbg для обох аргументов (pdbonly и full).
Они не влияют на оптимизацию кода.
Как плюсом могу отметить что документация на Github более актуальна, но она не открывает свет на специфическое поведение для debug+
Что на счет debug+?
debug+ это особенный аргумент, который не может быть заменен с помощью full и pdbonly. Как многие заметили, данный аргумент соответствует debug:full — это на самом деле не совсем правда. Если мы используем аргумент optimize-, поведение будет таким же, но для optimize+ будет свое собственное уникальное поведение (DebugFriendlyRelease).
debug- или без аргументов?
Значения по умолчанию, которые установлены в CSharpCommandLineParser.cs.
а значения для debug=:
Таким образом, мы можем с уверенностью сказать, что debug- и отсутствие аргументов отладки, приводет к одному и тому же эффекту — pdb файл не будет создан.
Запрет оптимизации JIT при загрузке модуля (Suppress JIT optimizations)
Флажок в разделе «Options->Debugging->General» это опция для отладчика в Visual Studio и не повлияет на сборки, которые вы создаете.
Вы должны теперь оценить, что компилятор JIT делает большую часть значительных оптимизаций и является большим препятствием для сопоставления исходного исходного кода для отладки. Если этот параметр включен, тогда он запросит DisableOptimizations.
Обычно этот параметр включаю для того чтобы отладить внешние библиотеки или пакеты NuGet.
Если мы хотим подключиться отладчиком Visual Studion к продакшен сборке, которая собрана в релизной конфигурации, то при наличии у нас pdb файла, мы может еще одним способом указать JIT компилятору, о том чтобы он не оптимизировал код. Для этого нужно добавить .ini файл с таким же названием как выполняемая библиотека и указать в нем:
Что такое Just My Code?
По умолчанию эта настройка уже включена (Options->Debugging→Enable Just My Code) и отладчик думает что оптимизированный код не является пользовательским. Поэтому отладчик никогда не зайдет в такой код.
Этот параметр стоит отключать в том случае, когда у вас есть pdb файл.
Взглянем ближе на DebuggableAttribute
Выше я упомянул использование ildasm для изучения манифеста сборок для изучения DebuggableAttribute. Я также написал небольшой PowerShell скрипт для получения более дружественного результата (ссылка на скачивание).
Читайте также: