Что такое debug и release
В чем отличие конфигураций сборки Debug (отладка) и Release (выпуск)?
В чем отличие Debug от Release
Народ, конкретно чем отличается дебаг от релиза. Я новичок совсем, поэтому не шарю. Но компилируя в.
Отличие Debug и Release версий exe
Уважаемые подскажите пожалуйста отличие Debug от Release версий exe, dll. Насколько я понимаю.
Кодировка в режиме сборки Debug / Release
В проекте использую только Use Multi-Byte Character Set, то есть ASCII. В режиме сборки Debug все.
Debug и Release сборки в Visual Studio
Я начал писать проект на c++ с использованием sfml. При сборке тестовой программы в версс debug.
Решение
Debug- это режим, в котором вы отлаживаете свой код на ошибки или ищите проблему в известном участке, но неизвестно какая проблема. В помощь приходит DEBUG, где вы можете установить точку остановки программы и определить причину сбоя программы.
Это режим в котором происходит сборка программы в единый файл.
Происходит тогда, когда вы нарушили какое то правило в коде или где-то допустили ошибку в правописание и.т.д
В настройках компиляции.
Если менять настройки ручками, то разница может быть только в названии, но по умолчанию в Release подключены оптимизации и отключено генерирование дополнительных инструкций для удобства отладки.
Компиляция — это процесс конвертирования программы на одном языке в программу на другом языке.
Устройство, выполняющее компиляцию.
Kazbek17, вы похоже ошибаетесь. Почти по всем пунктам можно взять и написать другой ответ.
The debug configuration of your program is compiled with full symbolic debug information and no optimization. Optimization complicates debugging, because the relationship between source code and generated instructions is more complex.
The release configuration of your program contains no symbolic debug information and is fully optimized. Debug information can be generated in PDB Files, depending on the compiler options that are used. Creating PDB files can be very useful if you later have to debug your release version.
В веб версии всё собирается в папку Bin. Она одна. Ну и по настройкам аналогично. Оно там собирается в разные папки, куда скажем туда и будет.
Что? Или слишком просто сказано или слишком неправильно.
Зачем это расписывать. Этот вопрос уже имеет в себе ответ. Нужно только указать на этот момент.
2. Для Release не желательно выключать Portable, поскольку этот файл крайне важен для логгирования Stack Trace.
3. С настройками по умолчанию брейкпоинты можно ставить. VS предложит вырубить Just My Code при самом первом запуске. Например, можно посмотреть значение temp, но нельзя temp2, это связано с конечным видом IL кода (IL2CPP, AOT и crossgen2 я особо не тестировал):
В чем разница между 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 скрипт для получения более дружественного результата (ссылка на скачивание).
Пара историй про отличия Release от Debug
Все разработчики знают, что исполнение релизной версии может отличаться от отладочной. В этой статье я расскажу пару случаев из жизни, когда такие отличия приводили к ошибочному исполнению программы. Примеры не отличаются большой сложностью, но вполне могут уберечь от наступления на грабли.
История 1
Собственно, началось все с того, что пришел баг о том что при некоторых операциях приложение вылетает. Это бывает часто. Баг не захотел воспроизводиться в Debug-версии. Это порой бывает. Поскольку в приложении часть библиотек была написано на C++, то первой мыслью было что-то вроде «где-то забыли переменную проинициализировать или что-то в этом духе». Но на деле суть бага крылась в управляемом коде, хотя без неуправляемого тоже не обошлось.
А код оказался примерно следующим:
protected virtual void Dispose( bool disposing)
<
if (disposing)
<
>
В принципе, практически каноническая реализация шаблона IDisposable («практически» — потому, что нет переменной disposed, вместо нее обнуление указателя), вполне стандартный класс-обертка неуправляемого ресурса.
Использовался же класс примерно следующим образом:
Естественно, что внимательный читатель сразу обратит внимание, что объекта wr надо вызвать Dispose, то есть обернуть все конструкцией using. Но на первый взгляд, на причину падения это не должно повлиять, так как разница будет в том детерминировано ли очистится ресурс или нет.
Но на самом деле разница есть и именно в релизной сборке. Дело в том, что объект wr становится доступным сборщику мусора сразу после начала выполнения метода DoCalculations, ведь больше нет ни одного «живого» объекта, кто на него ссылался бы. А значит wr вполне может(а так оно и происходило) быть уничтожен во время выполнения DoCalculations и указатель, переданный в этот метод становится невалидным.
Если обернуть вызов DoCalculations в using (Wrapper wr = new Wrapper())<. >, то это решит проблему, поскольку вызов Dispose в блоке finally, не даст жадному сборщику мусора «съесть» объект раньше времени. Если же по какой-то причине мы не можем или не хотим вызывать Dispose (к примеру WPF этот шаблон совсем не жалует), то придется вставлять GC.KeepAlive(wr) после вызова DoCalculations.
Реальный код, безусловно, был сложнее и разглядеть в нем ошибку было не так просто, как в примере.
Почему же ошибка проявлялась только в Release-версии, и то запущенной не из-под студии(если присоединить отладчик в процессе выполнения, то ошибка будет повторяться)? Потому что в противном случае для всех локальных ссылочных переменных добавляются якоря, чтобы они доживали до конца текущего метода, сделано это явно ради удобства отладки.
История 2
Жил-был проект, где для доступа к ресурсам использовался менеджер, который по строковому ключу доставал из заданной сборки различного вида ресурсы. С целью облегчения написания кода был написан следующего вида метод:
Чтобы «почувствовать разницу» предлагается следующий пример:
public void Method22()
<
( new Class1()).Method1();
>
>
dll3:
class Program
<
static void Main( string [] args)
<
( new Class3()).Method3();
>
>
class Class3
<
public void Method3()
<
( new Class2()).Method21();
>
>
Если скомпилировать в дебажной конфигурации(или если запускать процесс из-под студии) то получим честный стек вызовов:
в ClassLibrary1.Class1.Method1()
в ClassLibrary2.Class2.Method22()
в ClassLibrary2.Class2.Method21()
в ConsoleApplication1.Class3.Method3()
в ConsoleApplication1.Program.Main(String[] args)
Мораль здесь проста — не стоит привязывать логику к стеку вызовов, равно как и удивляться необычному стеку в исключениях в логе релизной версии. В частности, если вы пытаетесь найти причину исключения исключительно по его стеку вызовов, то стоит учитывать, что если стек заканчивается на методе Method1, то в коде оно(исключение) могло быть сгенерировано в одном из небольших методов, которые вызываются в теле Method1.
Так же на всякий случай стоит помнить, что можно запретить компилятору встраивать метод пометив его атрибутом [MethodImpl(MethodImplOptions.NoInlining)], эдакий аналог __declspec(noinline) в VC++.
Вместо заключения
Мир проявляемых только в релизе багов воистину безграничен, и цели сделать полный его обзор я не ставил. Просто хотелось поделиться собственным опытом, точнее более интересной его частью. Ну и остается только пожелать читателям поменьше сталкиваться с подобными ошибками в работе.
Урок №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?
Успехов. Еще раз Спасибо