Чем отличается debug от release в visual studio
Обновлено: 07.07.2024
- программа отлаживает файлы базы данных, которые позволяют достаточно внимательно следить за выполнением программы в исходном коде во время выполнения.
- все оптимизации отключены, что позволяет проверять значение переменных и трассировать в функции, которые в противном случае могли бы были оптимизированы прочь или в подкладке
- определение препроцессора _DEBUG, которое позволяет писать код, который действует по-разному в режиме отладки по сравнению с выпуском, например, чтобы инструмент утверждал, что должен использоваться только во время отладки
- связывание с библиотеками, которые также были скомпилированы с включенными параметрами отладки, которые обычно не развертываются для реальных клиентов (по причинам размера и безопасности)
в основном, debug включает в себя много дополнительной информации, полезной при отладке. В режиме выпуска все это сокращается и продается для производительности.
Если вы пройдете через параметры компиляции проекта и сравните их, вы увидите, каковы различия.
предполагая, что речь идет о собственном коде/C++ (это не совсем ясно из формулировки):
в принципе, в Debug все оптимизации генерации кода отключены. Некоторые библиотеки (например, STL) по умолчанию используют более строгую проверку ошибок (например, отладочные итераторы). Генерируется дополнительная отладочная информация (например, для "редактировать и продолжить"). Больше вещей генерируется в коде, чтобы поймать ошибки (значения локальных переменных установлены в неинициализированный шаблон, используется отладочная куча).
также обратите внимание, что при использовании MFC, например, отладочные проекты связываются с не распространяемыми версиями DLL, такими как MFC90D.DLL в то время как релиз строит ссылку против распространяемых версий, таких как MFC90.DLL . Вероятно, это похоже на другие фреймворки.
поэтому вы, вероятно, не сможете запускать отладочные приложения на машинах, не являющихся разработчиками.
кроме того, по-видимому, режим отладки создает много дополнительных потоков, чтобы помочь с отладкой. Они остаются активными в течение всего срока действия процесса, независимо от того, подключаете ли вы отладчик или нет. Смотрите мой связанный вопрос здесь.
очевидная разница, которую вы можете видеть, - это размер двоичного файла. Отладочная сборка создает двоичный файл большего размера, чем сборка выпуска.
при компиляции в Debug таблица символов добавляется в скомпилированный объект файла кода, что позволяет отладочным программам подключаться к этим двоичным файлам и оценивать значения объектов и переменных.
еще одно заметное различие заключается в том, что в режиме выпуска двоичный файл просто рухнет при фатальной ошибке в режиме отладки, если вы начните отладку приложения в Visual Studio, вы можете проверить стек вызовов, который сообщает вам точное местоположение ошибочного оператора.
мне тоже стало любопытно по этому вопросу, когда я разработал приложение, скопированное из существующей конфигурации сборки выпуска. У меня есть разработчик, который интересен в использовании этого приложения в режиме отладки, поэтому я задался вопросом, Что потребуется, чтобы сделать эту конфигурацию сборки, которая существует с именем ReleaseMyBuild, скопированным из конфигурации выпуска (и, следовательно, должен иметь все настройки, направленные на оптимизацию выпуска), чтобы внезапно изменить команды и стать сборкой отладки, несмотря на путаницу имя конфигурации сборки. Я решил, что конфигурация проекта-это просто имя и удобный способ выбрать "весь набор настроек", о которых упоминает Джорис Тиммерманс. Я хотел знать, что именно эти настройки могут быть такими, что делают конфигурацию сборки с именем " FOO " функцией оптимизированной релиз построить.
вот один взгляд на него, я создал новый VCXPROJ из пустого шаблона проекта из VS2010. Затем я скопировал его и отредактировал оба, первый сохраните содержимое отладки и второе содержимое выпуска. Вот разница, сосредоточенная на соответствующих различиях.
релиз
DEBUG
интересно, что в разделе ссылок у них обоих есть GenerateDebugInformation значение true.
Я не знаю, каковы точные различия, потому что на самом деле нет никакой информации, легко доступной на этом.
но основное наблюдаемое различие заключается в том, что версия выпуска иногда портит полученный DLL-файл и, таким образом, делает приложение, веб-приложение непригодным для использования.
к сожалению, вы должны поставить debug build в производство. И да, для публикации вы должны использовать старый добрый FTP.
Мне известно назначение каждой конфигурации и то, что в Release проводится оптимизация, а в Debug машинный код полностью соответствует написанному программистом. Ну и так же там объявляются разные константы ещё. Меня интересует какая именно отладочная информация содержится в сборке с конфигурацией Debug. По идее генерируется файл PDB и всё. Но ведь и в Release он так же создаётся. В чём разница? Встраивается ли именно в сам модуль какая то отладочная информация? Есть ещё какие то важные отличия между конфигурациями?
1,395 1 1 золотой знак 10 10 серебряных знаков 36 36 бронзовых знаков Relise - то же самое что Debug только без отладочных файлов, ресурсов, и других функций. За счёт чего работает быстрее и сборка меньше весит. Ну это понятно итак. Ваш ответ не соответствует вопросу. Но ведь и в Release он так же создаётся Можете в настройках отключить генерирование PDB файлов, если вам они не нужны в релизе. При чём тут нужны не нужны. Я про различия спрашиваю Вам уже выше ответили про различия. Если вам нужен конкретный, более точный ответ - пишите конкретный, более точный вопрос.Debug и Release - это просто названия стандартных конфигураций, создаваемых. Никаких завязок именно на имя конфигурации нет. Можно создать свою с названием, например, QQQ - через Build / Configuration Manager.
Поэтому эти конфигурации отличаются только тем, что выставлено для них по умолчанию в свойствах проекта:
Режимы Full от PDB Only отличается только тем, что в режиме Full на сборку навешивается атрибут DebuggableAttribute .
Этот атрибут прямо при старте приложения отключает некоторые оптимизации JIT, и заставляет JIT отслеживать соответствие смещения IL смещению в получаемом нативном коде, что позволяет отладчику более точно отслеживать текущую выполняемую строку.
И настройку оптимизации, и настройку трекинга отладчик может поменять в момент аттача к процессу, DebuggableAttribute просто позволяет сделать это заранее, так что даже методы, обработанные JIT до аттача, будут в неоптимизированном и удобном для отладки варианте.
Обычно первый этап происходит на вашем 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 скрипт для получения более дружественного результата (ссылка на скачивание).
Конфигурации сборок требуются для создания проектов с разными параметрами. Например, Debug и Release — это конфигурации, и при их создании используются разные параметры компилятора. Одна конфигурация является активной и отображается на панели команд в верхней части интегрированной среды разработки.
Этот раздел относится к Visual Studio в Windows. Информацию о Visual Studio для Mac см. в статье Конфигурации сборки в Visual Studio для Mac.
Параметры "Конфигурация" и "Платформа" позволяют определить, где будут храниться выходные файлы сборки. Как правило, когда в Visual Studio выполняется сборка проекта, выходные данные помещаются во вложенную папку проекта с именем активной конфигурации (например, bin/debug/x86). Но это можно изменить.
Вы можете создавать свои конфигурации сборки на уровне решения и проекта. Конфигурация решения определяет, какие проекты включаются в сборку, когда эта конфигурация активна. В сборку будут включены только проекты, указанные в активной конфигурации решения. Если в Configuration Manager выбрано несколько целевых платформ, будут построены все проекты, которые применяются к этой платформе. Конфигурация проекта определяет, какие параметры сборки и компилятора используются при сборке проекта.
Чтобы создать, выбрать, изменить или удалить конфигурацию, можно использовать Configuration Manager. Чтобы открыть его, выберите в строке меню Сборка > Configuration Manager или просто введите Configuration в поле поиска. Можно также использовать список Конфигурации решения на панели инструментов Стандартные, чтобы выбрать конфигурацию или открыть Configuration Manager.
Если вы не можете найти параметры конфигурации решения на панели инструментов и не можете получить доступ к Configuration Manager, можно применить параметры развертывания Visual Basic. Дополнительные сведения см. в разделе Практическое руководство. Управление конфигурациями с применением параметров разработчика Visual Basic.
По умолчанию конфигурации Debug и Release включены в проекты, которые создаются с использованием шаблонов Visual Studio. Конфигурация Debug поддерживает отладку приложения, а конфигурация Release создает версию приложения, которое можно развернуть. Дополнительные сведения см. в разделе Практическое руководство. Настройка конфигураций отладки и выпуска. Можно также создать пользовательские конфигурации решений и проектов. Дополнительные сведения см. в разделе Практическое руководство. создавать и изменять конфигурации.
Конфигурации решения
Конфигурация решения указывает, как следует создавать и развертывать проекты в решении. Чтобы изменить конфигурацию решения или определить новую конфигурацию в Configuration Manager, в меню Активная конфигурация решения щелкните Изменить или Создать.
Каждая запись в поле Контексты проекта в конфигурации решений представляет проект в решении. Для каждой комбинации Активная конфигурация решения и Активная платформа решения можно задать способ использования каждого проекта. (Дополнительные сведения о платформах решений см. в разделе Общие сведения о сборках платформ.)
При определении новой конфигурации решения и установке флажка Создать новые конфигурации проектовVisual Studio автоматически назначает новую конфигурацию всем проектам. Аналогичным образом, при определении новой платформы решения и установке флажка Создать новые платформы проектовVisual Studio автоматически назначает новую платформу всем проектам. Кроме того, если вы добавите проект, предназначенный для новой платформы, Visual Studio добавит эту платформу в список платформ решений и назначит ее всем проектам. Вы по-прежнему можете изменять параметры для каждого проекта.
Активная конфигурация решения также предоставляет контекст для IDE. Например, если вы работаете над проектом и конфигурация указывает, что он будет создан для мобильного устройства, на панели инструментов отобразятся только элементы, которые можно использовать в проекте мобильного устройства.
Конфигурации проекта
Параметры сборки и компилятора, используемых при сборке проекта определяют конфигурация и целевая платформа. В проекте могут быть разные параметры для каждой комбинации конфигурации и платформы. Чтобы изменить свойства проекта, откройте контекстное меню проекта в обозревателе решений и щелкните Свойства. В верхней части вкладки Сборка конструктора проектов выберите активную конфигурацию, чтобы изменить параметры сборки.
Сборка нескольких конфигураций
При построении решения с помощью команды Сборка > Собрать решение, Visual Studio выполняет сборку только активной конфигурации. Все проекты, указанные в этой конфигурации решения, будут построены, и единственной конфигурацией проекта будет только одна из них, указанная в активной конфигурации решения и активной платформе решения, которая отображается на панели инструментов в Visual Studio. Например, Отладка и x86. Другие определенные конфигурации и платформы не создаются.
Если требуется создать несколько конфигураций и платформ в одном действии, можно использовать параметр Сборка > Пакетная сборка в Visual Studio. Для получения доступа к этой функции, нажмите Ctrl+Q, чтобы открыть поле поиска, и введите Batch build . Пакетная сборка доступна не для всех типов проектов. См. практическое руководство по сборке с использованием нескольких конфигураций.
Назначение конфигураций проектов Visual Studio
Если вы определяете конфигурацию нового решения и не копируете параметры из существующего, Visual Studio использует следующие критерии для назначения конфигурации проектов по умолчанию. Критерии оцениваются в следующем порядке.
Если проект имеет имя конфигурации ( <configuration name> <platform name> ), которое точно совпадает с именем новой конфигурации решения, назначается эта конфигурация. В именах конфигураций не учитывается регистр.
Если проект имеет имя конфигурации, в котором часть имени конфигурации совпадает с новой конфигурацией решения, назначается эта конфигурация (независимо от того, совпадает ли часть имени платформы или нет).
Если совпадений все равно нет, назначается первая конфигурация, указанная в проекте.
Назначение конфигураций решений Visual Studio
При создании конфигурации проекта (в Configuration Manager путем выбора пункта Создать в раскрывающемся меню столбца Конфигурация для этого проекта) и установке флажка Создать новые конфигурации решений Visual Studio ищет конфигурацию решения с таким же именем, чтобы создать проект на каждой поддерживаемой платформе. В некоторых случаях Visual Studio переименовывает существующие конфигурации решения или определяет новые.
Visual Studio использует следующие критерии для назначения конфигураций решения.
Если конфигурация проекта не указывает платформу или указывает только одну платформу, будет найдена или добавлена конфигурация решения, имя которой совпадает с именем новой конфигурации проекта. Имя по умолчанию конфигурации решения не включает имя платформы; оно имеет формат <project configuration name> .
Если проект поддерживает несколько платформ, для каждой поддерживаемой платформы будет найдена или добавлена конфигурация решения. Имя каждой конфигурации решения включает как имя конфигурации проекта, так и имя платформы, и имеет формат <project configuration name> <platform name> .
Режимы debug и release - в чем принципиальная разница?
Ситуация такая: есть довольно древний проект на VS 2008, и мне приходится его поддерживать.
В чем разница между Debug and Release?
Какие действия выполняет debug в Visual studio и какие Release, в чем разница? Никогда не задавался.
Разница между Debug и Release
Какая разница в них? Я только знаю,что при компиляции Debug ми не можем увидеть как.
Разница в выводе графики между release и debug
Добрый день. Пример из книги М. Шлее. Qt версия 5.7. У всех так, или только у меня картинки разные.
С компилятором это никак не связано
Minimum supported client Windows Vista [desktop apps | Windows Store apps]
Скорее всего, релизная сборка не настроена
как Windows XP (v110_xp)
в Debug включена отладочная информация
программа может требовать отладочных библиотек которых нет на других компьютерах
в Release включена оптимизация, размер файла уменьшается, скорость увеличивается
сильно подозреваю, что при Debug была включена статическая линковка и программа вобрала в себя все библиотеки, а при Release динамическая
Добавлено через 3 минуты
Debug или Release?
прямо по шагам пройди и сравни настройки В релиз тоже отладочная информация просачивается. Например, Qt пришлось специально настройки подкручивать чтоб assert(false) в релизе не работало. Да и программы падающие с ошибками в стиле "произошла ошибка в строке 1234 файла бла-бла-бла.cpp" тоже попадались, хотя и не часто. Ну вот откуда во вроде бы релиз-версии данные об этом бла-бла-бла.cpp взялись? Видимо, не у одного меня такие неправильные компиляторы, которые тихой сапой пихают в релиз отладочные данные.
для этого нужно постараться
включить спецовый ключик, по умолчанию он обычно выключен, хотя у кого как
если не хочешь чтобы твою программу увели, то отключай отладочную информацию
при дизасемблировании видны имена функций
если хочешь сам баг найти то включай
на на VS 2008 была выключена по умолчанию, после какого то сервис пака по умолчанию включена
Добавлено через 3 минуты
да забыл добавить в Debug в VS по крайней мере включены "подушки безопасности" выделяешь память под массив на 5 элементов он выделяет 10( условно), отслеживает выход за пределы массива
плюс при входе в функцию защищает стек
Читайте также: