Чем отличаются конфигурации сборки отладка debug и выпуск release

Урок №6. Режимы конфигурации «Debug» и «Release»

Конфигурация сборки (англ. «build configuration») — это набор настроек проекта, которые определяют принцип его построения. Конфигурация сборки состоит из:

имени исполняемого файла;

имени директории исполняемого файла;

имён директорий, в которых IDE будет искать другой код и файлы библиотек;

информации об отладке и параметрах оптимизации вашего проекта.

Интегрированная среда разработки имеет две конфигурации сборки: «Debug» (Отладка) и «Release» (Релиз).

Конфигурация «Debug» предназначена для отладки вашей программы. Эта конфигурация отключает все настройки по оптимизации, включает информацию об отладке, что делает ваши программы больше и медленнее, но упрощает проведение отладки. Режим «Debug» обычно используется в качестве конфигурации по умолчанию.

Конфигурация «Release» используется во время сборки программы для её дальнейшего выпуска. Программа оптимизируется по размеру и производительности и не содержит дополнительную информацию об отладке.

Например, исполняемый файл программы «Hello, World!» из предыдущего урока, созданный в конфигурации «Debug», у меня занимал 65 КБ, в то время как исполняемый файл, построенный в конфигурации «Release», занимал всего лишь 12 КБ.

Переключение между режимами «Debug» и «Release» в Visual Studio

Самый простой способ изменить конфигурацию проекта — выбрать соответствующую из выпадающего списка на панели быстрого доступа:

Переключение между режимами «Debug» и «Release» в Code::Blocks

В Code::Blocks на панели быстрого доступа есть также выпадающий список, где вы можете выбрать соответствующий режим конфигурации:

Заключение

Используйте конфигурацию «Debug» при разработке программ, а конфигурацию «Release» при их релизе.

Поделиться в социальных сетях:

Урок №5. Компиляция вашей первой программы

Комментариев: 16

Здравствуйте. Спасибо, отличный курс.
Вопрос. Как реализовать режим Release в командной строке, используя Mingw?
Успехов. Еще раз Спасибо

Источник

В чем разница между Debug и Release в Visual Studio?

в чем разница между Debug и Release в Visual Studio?

10 ответов:

«Debug» и «Release» на самом деле являются всего лишь двумя метками для целого ряда настроек, которые могут повлиять на вашу сборку и отладку.

В режиме «Debug» у вас обычно есть следующее:

в режиме» Release » включены оптимизации on (хотя доступно несколько параметров) и определение препроцессора _DEBUG не определено. Обычно вы все равно захотите создать файлы PDB, потому что очень полезно иметь возможность «отлаживать» в режиме выпуска, когда все работает быстрее.

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

Если вы пройдете через параметры компиляции проекта и сравните их, вы увидите, каковы различия.

предполагая, что речь идет о собственном коде/C++ (это не совсем ясно из формулировки):

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

вероятно, стоит упомянуть очень очевидное, что флаги сборки допускают различную логику, которая должны используется только для изменения регистрации и» консольных » сообщений, но can злоупотреблять и резко изменить не только низкие уровни, но и фактическую бизнес-логику.

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

кроме того, по-видимому, режим отладки создает много дополнительных потоков, чтобы помочь с отладкой. Они остаются активными в течение всего срока действия процесса, независимо от того, подключаете ли вы отладчик или нет. Смотрите мой связанный вопрос здесь.

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

еще одно заметное различие заключается в том, что в режиме выпуска двоичный файл просто рухнет при фатальной ошибке в режиме отладки, если вы начните отладку приложения в Visual Studio, вы можете проверить стек вызовов, который сообщает вам точное местоположение ошибочного оператора.

мне тоже стало любопытно по этому вопросу, когда я разработал приложение, скопированное из существующей конфигурации сборки выпуска. У меня есть разработчик, который интересен в использовании этого приложения в режиме отладки, поэтому я задался вопросом, Что потребуется, чтобы сделать эту конфигурацию сборки, которая существует с именем ReleaseMyBuild, скопированным из конфигурации выпуска (и, следовательно, должен иметь все настройки, направленные на оптимизацию выпуска), чтобы внезапно изменить команды и стать сборкой отладки, несмотря на путаницу имя конфигурации сборки. Я решил, что конфигурация проекта-это просто имя и удобный способ выбрать «весь набор настроек», о которых упоминает Джорис Тиммерманс. Я хотел знать, что именно эти настройки могут быть такими, что делают конфигурацию сборки с именем » FOO » функцией оптимизированной релиз построить.

вот один взгляд на него, я создал новый VCXPROJ из пустого шаблона проекта из VS2010. Затем я скопировал его и отредактировал оба, первый сохраните содержимое отладки и второе содержимое выпуска. Вот разница, сосредоточенная на соответствующих различиях.

релиз

DEBUG

интересно, что в разделе ссылок у них обоих есть GenerateDebugInformation значение true.

Я не знаю, каковы точные различия, потому что на самом деле нет никакой информации, легко доступной на этом.

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

к сожалению, вы должны поставить debug build в производство. И да, для публикации вы должны использовать старый добрый FTP.

Источник

Богдан Стефанюк

Из коробки в C# нам доступны 2 способа сборки проекта release и debug.

О компиляции C# кода

Исходный код C # проходит через 2 этапа компиляции, чтобы стать инструкциями CPU, которые могут быть выполнены.

Обычно первый этап происходит на вашем CI сервере, а второй шаг происходит позже, во время работы самого приложения. Когда же мы работаем локально в Visual Studio, то она все эти шаги выполняет перед запуском приложения из меню Debug.

Шаг первый. Компиляция приложения
Ваш код превращается в Common Intermediate Language (CIL), который уже может быть выполнен в любом окружении, которое поддерживает CIL. Обратите внимание, что собранная сборка не является читаемым текстом IL, а фактически метаданными и байтовым кодом в виде двоичных данных.

На данном шаге будет выполнена некоторая оптимизация кода (будет описано дальше).

Шаг второй. JIT компилятор
JIT компилятор конвертирует IL код в инструкции процессора, которые можно выполнить на вашей машине. Однако не вся компиляция происходит заранее — в нормальном режиме, код компилируется, только тогда когда его вызывают в первый раз, после чего он кэшируется.

Основная часть оптимизации кода будет проведена на этом шаге.

Что такое оптимизация кода в одном предложении?

Почему мы заинтересованы в оптимизации в этой статье?

На обоих этапах компиляции ваш код будет оптимизирован компиляторами. Одно из ключевых различий между конфигурациями сборки Debug и Release заключается в том, отключены ли оптимизации или нет, поэтому нам нужно понять последствия данных оптимизации.

Оптимизация компилятора C#

C# компилятор на самом деле делает очень мало оптимизаций. На самом деле большенство оптимизаций производит JIT компилятор во время генерирования машинного кода. Тем не менее это все равно ухудшит работу по отладке.

Инструкция nop в IL
Команда nop имеет ряд применений при программировании на низком уровне, например, для включения небольших предсказуемых задержек или инструкции по перезаписи, которые вы хотите удалить. В IL коде данные конструкции помогают при использовании точек останова (breakpoints) для того чтобы они вели себя предсказуемо.

Если мы посмотрим на IL код, который сгенерирован с отключенными оптимизациями:

Эта инструкция мапиться с фигурной скобкой, для того чтобы мы могли поставить на нее точку остановки:

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

Более подробное обсуждение оптимизаций компилятора C# в статье Эрика Липперта: Что делает переключатель оптимизации?. Существует также хороший комментарий о IL до и после оптимизации здесь.

Оптимизация JIT компилятора

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

Я рассмотрю один пример, чтобы проиллюстрировать влияние оптимизации на отладку.
Встраивание методов

Для реальной оптимизации, сделанной компилятором JIT, я буду показывать инструкции по сборке. Это всего лишь макет на C #, чтобы дать вам общую идею.

Предположим, что у меня есть:

Компилятор JIT, скорее всего, выполнит встроенное расширение. Он заменит вызов метода Add() телом данного метода:

Конфигурации сборки по умолчанию

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

Внутренности аргументов оптимизации и отладки

Я попытался продемонстрировать данные аргументы из кода Roslyn и mscorlib. Теперь мы имеем следующие классы:

Синие элементы обозначаю аргументы командной строки, а зеленые их представление в коде.

Перечисление OptimizationLevel

OptimizationLevel.Debug отключает все оптимизации для C# и JIT компилятора с помощью DebuggableAttribute.DebuggingModes, который с помощью ildasm, мы можем видеть:

OptimizationLevel.Release включает все оптимизации (DebuggableAttribute.DebuggingModes = ( 01 00 02 00 00 00 00 00 )) что в свою очередь соответсвует DebuggingModes.IgnoreSymbolStoreSequencePoints

При этом уровне оптимизации точки останова могут быть оптимизированы. Что приведет к тому что мы не сможем их поставить и остановиться.

Типы IL

Типы IL кода описаны в классе ILEmitStyle.

На диаграмме выше показано, что тип генерируемого IL кода C# компилятором зависит от OptimizationLevel.
Аргумент debug не меняет его, за исключение аргумента debug+ когда OptimizationLevel установлен в Release.

Следующий кусок кода продемонстрирует все это наглядно.

Комментарий в исходном файле Optimizer.cs гласит, что они не опускают никаких определенных пользователем локальных переменных (примеры на 28 строчке) и не переносят значения в стек между операторами.

Я рад, что прочитал это, так как я был немного разочарован своими собственными экспериментами в ildasm с debug +, поскольку все, что я видел, это сохранение локальных переменных.

Нет намеренной «деоптимизации», например, добавления команд nop.

Разница между debug, debug:full и debug:pdbonly.

На самом деле разницы никакой нету, что подтверждает официальная документация:

Результат остается одним и тем же — pdb файл создается.
Подгланув в CSharpCommandLineParser можем убедиться в этом. И для того чтобы проверить это, мне удалось отладить код с помощью WinDbg для обох аргументов (pdbonly и full).

Они не влияют на оптимизацию кода.
Как плюсом могу отметить что документация на Github более актуальна, но она не открывает свет на специфическое поведение для debug+

А что же такое этот ваш pdb файл?
Все очень просто, данный файл содержит всю необходимую информацию для отладки DLL и EXE. Что помогает сопоставить отладчику IL код с инструкциями в оригинальном C# коде.

Что на счет 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.

Что такое Just My Code?

По умолчанию эта настройка уже включена (Options->Debugging→Enable Just My Code) и отладчик думает что оптимизированный код не является пользовательским. Поэтому отладчик никогда не зайдет в такой код.

Вы можете отключить данный флаг и это, теоретически, позволит вам поставить точку остановки. Но теперь вы отлаживаете код, оптимизированный как компиляторами C# так и JIT, который едва соответствуют исходному коду. В результате у вас будут такие артефакты отладки, как непредсказуемые переходы в коде и скорее все вам не получиться получить значения в локальных переменных.

Этот параметр стоит отключать в том случае, когда у вас есть 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

Если вы определяете конфигурацию нового решения и не копируете параметры из существующего, Visual Studio использует следующие критерии для назначения конфигурации проектов по умолчанию. Критерии оцениваются в следующем порядке.

Если проект имеет имя конфигурации (

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

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

Если совпадений все равно нет, назначается первая конфигурация, указанная в проекте.

Назначение конфигураций решений Visual Studio

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

Visual Studio использует следующие критерии для назначения конфигураций решения.

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

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

Источник

Настройка конфигураций отладки и выпуска в Visual Studio

Проекты Visual Studio имеют отдельные конфигурации выпуска и отладки для вашей программы. Производится построение отладочной версии для отладки и версии выпуска для окончательного выпуска программы.

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

Конфигурация выпуска для программы полностью оптимизируется и не содержит символической отладочной информации. Для управляемого кода и кода C++ отладочная информация может быть создана в виде PDB-файлов в зависимости от используемых параметров компилятора. Создание PDB-файлов может оказаться полезным, если позднее возникнет необходимость в отладке версии выпуска.

Дополнительные сведения о конфигурациях сборки см. в статье Общие сведения о конфигурациях сборки.

Конфигурацию сборки можно изменить в меню Сборка на панели инструментов или на страницах свойств проекта. Страницы свойств проекта зависят от конкретного языка. Следующая процедура показывает, как изменить конфигурацию сборки из меню и на панели инструментов. Дополнительные сведения об изменении конфигурации сборки в проектах на разных языках см. в разделе См. также ниже.

Изменение конфигурации сборки

Для изменения конфигурации сборки сделайте следующее.

На панели инструментов выберите либо Отладка, либо Выпуск из списка Конфигурации решения.

Создание файлов символов (PDB) для сборки (C#, C++, Visual Basic, F#)

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

Отладчик загружает PDB-файл для исполняемого файла, только если он точно соответствует PDB-файлу, который был создан при сборке исполняемого файла (то есть это должен быть либо оригинальный PDB-файл, либо его копия). Дополнительные сведения см. в статье Почему Visual Studio требует, чтобы файлы символов отладчика точно соответствовали двоичным файлам, с которыми они были собраны?

Каждый тип проекта может иметь свой способ установки этих параметров.

Создание файлов символов для проекта C#, ASP.NET или Visual Basic

Дополнительные сведения о параметрах проекта для конфигурации отладки C# и Visual Basic см. в статьях Параметры проектов для конфигураций отладки C# и Параметры проекта для конфигурации отладки Visual Basic.

Выберите проект в Обозревателе решений.

Выберите значок Свойства (или нажмите клавишу ALT+ВВОД).

В боковой области выберите Сборка (или Компилировать в Visual Basic).

В списке Конфигурация выберите Отладка или Выпуск.

Нажмите кнопку Дополнительно (или Дополнительные параметры компиляции в Visual Basic).

В списке Сведения об отладке (или Создать сведения об отладке в Visual Basic) выберите Полные, Только для PDB или Переносимые.

Компилятор создает файлы символов в той же папке, что и исполняемый файл или основной выходной файл.

Создание файлов символов для проекта C++

Выберите проект в Обозревателе решений.

Выберите значок Свойства (или нажмите клавишу ALT+ВВОД).

В списке Конфигурация выберите Отладка или Выпуск.

В боковой области выберите Компоновщик > Отладка, а затем выберите параметры в разделе Создать сведения об отладке.

Дополнительные сведения о параметрах проекта для конфигурации отладки C++ см. в разделе Параметры проекта для конфигурации отладки C++.

Настройте параметры для раздела Создание файлов базы данных программы.

Компилятор создает файлы символов в той же папке, что и исполняемый файл или основной выходной файл.

Источник