Чем debug отличается от release с

Какая разница что использовать: Debug или Release? Должен быть толк от этого, лично я использую всегда Debug, по умолчанию, нужно ли менять? В учебнике об этом вообще ни слова ни пишут.

Изображения

QIP Shot — Screen 001.jpg (101.0 Кб, 128 просмотров)

Регистрация: 15.02.2010
Сообщений: 15,558
Использовать для чего? Вы знаете, что такое отладка? Что такое отладчик?
Форумчанин
Регистрация: 12.06.2018
Сообщений: 831
Сообщение от p51x
Использовать для чего? Вы знаете, что такое отладка? Что такое отладчик?
Знаю конечно! Но зачем 2??
Регистрация: 22.05.2007
Сообщений: 9,507
Для разработки — Debug. Для использования пользователями — Release.
Форумчанин
Регистрация: 12.06.2012
Сообщений: 110

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

shturman1387

Посмотреть профиль

Найти ещё сообщения от shturman1387

Форумчанин
Регистрация: 12.12.2010
Сообщений: 205
Так и быть, помогу.
Регистрация: 30.12.2009
Сообщений: 11,442

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

Потому дебаг для разработки, а relaase для пользователей. Причина тому проста:
1. Эта информация там не нужна никому.
2. Из информации для отладчика, можно запросто восстановить исходный код программы, или же сильно упростить этот процесс.

Человек_Борща

Посмотреть профиль

Найти ещё сообщения от Человек_Борща

Пара историй про отличия Release от Debug

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

История 1

Собственно, началось все с того, что пришел баг о том что при некоторых операциях приложение вылетает. Это бывает часто. Баг не захотел воспроизводиться в Debug-версии. Это порой бывает. Поскольку в приложении часть библиотек была написано на C++, то первой мыслью было что-то вроде «где-то забыли переменную проинициализировать или что-то в этом духе». Но на деле суть бага крылась в управляемом коде, хотя без неуправляемого тоже не обошлось.

А код оказался примерно следующим:

public Wrapper()
this .Obj = CreateUnmObject();
>

~Wrapper()
this .Dispose( false );
>

protected virtual void Dispose( bool disposing)
if (disposing)
>

this .ReleaseUnmObject( this .Obj);
this .Obj = IntPtr .Zero;
>

public void Dispose()
this .Dispose( true );
GC.SuppressFinalize( this );
>
>

* This source code was highlighted with Source Code Highlighter .

В принципе, практически каноническая реализация шаблона IDisposable («практически» — потому, что нет переменной disposed, вместо нее обнуление указателя), вполне стандартный класс-обертка неуправляемого ресурса.

Использовался же класс примерно следующим образом:

* This source code was highlighted with Source Code Highlighter .

Естественно, что внимательный читатель сразу обратит внимание, что объекта wr надо вызвать Dispose, то есть обернуть все конструкцией using. Но на первый взгляд, на причину падения это не должно повлиять, так как разница будет в том детерминировано ли очистится ресурс или нет.

Но на самом деле разница есть и именно в релизной сборке. Дело в том, что объект wr становится доступным сборщику мусора сразу после начала выполнения метода DoCalculations, ведь больше нет ни одного «живого» объекта, кто на него ссылался бы. А значит wr вполне может(а так оно и происходило) быть уничтожен во время выполнения DoCalculations и указатель, переданный в этот метод становится невалидным.

Если обернуть вызов DoCalculations в using (Wrapper wr = new Wrapper())<. >, то это решит проблему, поскольку вызов Dispose в блоке finally, не даст жадному сборщику мусора «съесть» объект раньше времени. Если же по какой-то причине мы не можем или не хотим вызывать Dispose (к примеру WPF этот шаблон совсем не жалует), то придется вставлять GC.KeepAlive(wr) после вызова DoCalculations.

Реальный код, безусловно, был сложнее и разглядеть в нем ошибку было не так просто, как в примере.

Почему же ошибка проявлялась только в Release-версии, и то запущенной не из-под студии(если присоединить отладчик в процессе выполнения, то ошибка будет повторяться)? Потому что в противном случае для всех локальных ссылочных переменных добавляются якоря, чтобы они доживали до конца текущего метода, сделано это явно ради удобства отладки.

История 2

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

public string GetResource( string key)
Assembly assembly = Assembly .GetCallingAssembly();
return this .GetResource(assembly, key);
>

* This source code was highlighted with Source Code Highlighter .

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

Чтобы «почувствовать разницу» предлагается следующий пример:

dll1:
public class Class1
public void Method1()
Console .WriteLine( new StackTrace());
>
>

dll2:
public class Class2
public void Method21()
this .Method22();
>

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();
>
>

* This source code was highlighted with Source Code Highlighter .

Если скомпилировать в дебажной конфигурации(или если запускать процесс из-под студии) то получим честный стек вызовов:
в ClassLibrary1.Class1.Method1()
в ClassLibrary2.Class2.Method22()
в ClassLibrary2.Class2.Method21()
в ConsoleApplication1.Class3.Method3()
в ConsoleApplication1.Program.Main(String[] args)

Если собрать под .Net версии до 3.5 включительно в релизе:
в ClassLibrary1.Class1.Method1()
в ClassLibrary2.Class2.Method21()
в ConsoleApplication1.Program.Main(String[] args)

А под .Net 4 в релизной конфигурации то и вовсе получим:
в ConsoleApplication1.Program.Main(String[] args)

Мораль здесь проста — не стоит привязывать логику к стеку вызовов, равно как и удивляться необычному стеку в исключениях в логе релизной версии. В частности, если вы пытаетесь найти причину исключения исключительно по его стеку вызовов, то стоит учитывать, что если стек заканчивается на методе Method1, то в коде оно(исключение) могло быть сгенерировано в одном из небольших методов, которые вызываются в теле Method1.

Так же на всякий случай стоит помнить, что можно запретить компилятору встраивать метод пометив его атрибутом [MethodImpl(MethodImplOptions.NoInlining)], эдакий аналог __declspec(noinline) в VC++.

Вместо заключения

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

Чем отличается Debug от Release в Visual Studio?

ulrich-schnauss

Список параметров вы можете увидеть в свойствах проекта.

Ответ написан более трёх лет назад
Комментировать
Нравится 1 Комментировать
Love Family, Love Code

В свойствах проекта можно глянуть разницу
Опции для юилда слегка отличаются по умолчанию.
Аналогично в web config

Ответ написан более трёх лет назад
Комментировать
Нравится Комментировать
Дмитрий Ковальский @dmitryKovalskiy
программист средней руки

Данные режимы отличаются настройками конфигураций. web.config — общие настройки на все конфигурации. web.debug.config и web.release.config — настройки конкретных конфигураций. Ну и если вы используете конструкцию #if DEBUG
в вашем коде — то в конфигурации release эти инструкции не будут компилироваться и включаться в конечные сборки.

Ответ написан более трёх лет назад
Комментировать
Нравится Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

C#
+1 ещё

Как проверить соприкасаются ли два изображения или нет winforms c#?

1 подписчик
46 минут назад
59 просмотров

какая разница между Debug и Release. можно поподробнее

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

Лучший ответ

Debug и Release это не какие-то стандартные штуки. Можно добавлять свои.

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

Можно сделать Release такой что там не будет оптимизаций.

Иногда можно встретить Production в которой оптимизации включены.

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

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

Остальные ответы

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

в Release этого нету, поэтому меньше весит и меньше файлов

Debug это логирование. Про release я мало чего знаю. Это что то типо перевыпуска, перезапуска

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

Release — это полностью готовая программа, используемая в «боевом» режиме.

Kostja J.Профи (872) 4 года назад

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

Чем debug отличается от release с