В чем разница между отладкой и выпуском в Visual Studio?

Ответы:

114

Самое главное, что в режиме Debug оптимизаций нет, а в режиме Release есть оптимизации. Это важно, потому что компилятор очень продвинутый и может выполнять довольно сложные низкоуровневые улучшения вашего кода. В результате некоторые строки вашего кода могут остаться вообще без каких-либо инструкций, а некоторые могут быть перепутаны. Пошаговая отладка была бы невозможна. Кроме того, локальные переменные часто оптимизируются таинственным образом, поэтому часы и быстрые часы часто не работают, потому что переменная «оптимизирована». И есть множество других оптимизаций. Попробуйте как-нибудь отладить оптимизированный код .NET, и вы увидите.

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

Вилкс-
источник
1
«В результате некоторые строки вашего кода могут остаться вообще без каких-либо инструкций, а некоторые могут вообще запутаться». Ага, ошиблись с этим, используя кадры стека, чтобы получить имя текущего метода / свойства - и многие свойства были встроены в выпуск ...
kpollock
4
«Самое главное, что в режиме отладки нет оптимизаций» - то спорно. самое главное, что есть отладочная информация, которая позволяет вам отлаживать. хотя это может существовать и в выпуске.
Shoosh
Я не знаю, какой режим используется по умолчанию (отладка / выпуск). Как правило, по моему опыту, все проекты находятся в режиме отладки, и команда установщиков позаботится об этом выпуске, чтобы избежать файла pdb и внести оптимизацию. Но сегодня я столкнулся с ситуацией, когда режим изменен на релиз, и я не могу взломать код, используя точку останова. Я пробовал долго делать много вещей и, наконец, заметил, что это из-за проблемы с текущим режимом компиляции. @ Vlix - Спасибо за ответ.
kbvishnu
1
Это фактически помогло мне решить проблему «Имя 'переменная' не существует в текущем контексте», с которой я столкнулся при попытке проанализировать символ в непосредственном окне при отладке приложения, соблюдающего конфигурацию выпуска по умолчанию. Большое спасибо!
M463
1) Что насчет следующих вопросов? В проекте ASP.NET MVC есть 3 конфигурации: базовая (веб), отладочная (web.debug), выпуск (web.release). Предположим, мы установили строку подключения отладки и выпуска путем преобразования в соответствующую конфигурацию (отладка и выпуск). При публикации мы можем публиковать в соответствии с нашим выбором в диалоговом окне публикации. Но при запуске приложения, несмотря на то, что я выбираю «Отладка», оно использует конфигурацию выпуска (поскольку я установил конфигурацию отладки в базовой и отладочной конфигурации), это нормально?
Джейсон
52

«Отладка» и «Выпуск» - это на самом деле всего лишь две метки для целого ряда настроек, которые могут повлиять на вашу сборку и отладку.

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

  • Файлы Program Debug Database, которые позволяют вам достаточно внимательно следить за выполнением программы в исходном коде во время выполнения.
  • Все оптимизации отключены, что позволяет вам проверять значение переменных и отслеживать функции, которые в противном случае могли бы быть оптимизированы отдельно или встроены
  • Определение препроцессора _DEBUG, которое позволяет писать код, который в режиме отладки действует иначе, чем в выпуске, например, для инструментария ASSERT, которые следует использовать только во время отладки.
  • Связывание с библиотеками, которые также были скомпилированы с включенными параметрами отладки, которые обычно не развертываются для реальных клиентов (по причинам размера и безопасности)

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

Йорис Тиммерманс
источник
5
«всего две метки» - на самом деле Visual Studio дает вам возможность создавать больше! Это может быть исключительно полезно при тестировании программы. Например, я недавно написал программу для своей работы, которая принимает имена файлов из командной строки. Я протестировал синтаксический анализ командной строки, но как только это было сделано, я не хотел каждый день возиться с CMD и списками имен файлов; Я создал конфигурацию, с которой я мог использовать условную компиляцию для предоставления фиктивных значений командной строки и тестирования бизнес-логики программы, что дало мне намного более быстрый цикл итераций при разработке программы.
Brian S
9

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

Rik
источник
1) Что насчет следующих вопросов? В проекте ASP.NET MVC есть 3 конфигурации: базовая (веб), отладочная (web.debug), выпуск (web.release). Предположим, мы установили строку подключения отладки и выпуска путем преобразования в соответствующую конфигурацию (отладка и выпуск). При публикации мы можем публиковать в соответствии с нашим выбором в диалоговом окне публикации. Но при запуске приложения, несмотря на то, что я выбираю «Отладка», оно использует конфигурацию выпуска (поскольку я установил конфигурацию отладки в базовой и отладочной конфигурации), это нормально?
Джейсон
2) При запуске приложения в режиме отладки или выпуска VS использует базовую веб-конфигурацию или соответствующую веб-конфигурацию (web.debug.confg или web.release.config)?
Джейсон
7

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

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

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

NeARAZ
источник
2
@Vilx: когда я ответил, тега .net еще не было, только visualstudio. Я решил, что это C ++.
NeARAZ
6

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

Мэтт Якобсен
источник
Но только для .NET (не C ++)?
Питер Мортенсен
6

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

аннаката
источник
«... кардинально изменить ... реальную бизнес-логику» - звучит для меня как ошибка! У нас много условного кода, и его очень сложно понять. Кроме того, каждая комбинация условных флагов кода - это, по сути, другая версия вашего программного обеспечения, которую следует тестировать, чтобы гарантировать правильность и базовую целостность. Согласно «Code Complete», моей Библии построения программного обеспечения, наша «основная директива» - это управление сложностью. (Это наша проблема №1, которую необходимо решить). Хорошо подумайте, прежде чем без разбора добавлять дополнительные условные флаги!
MicroservicesOnDDD
Мой вышеупомянутый комментарий не был направлен на этот ответ, в частности, что касается последнего предложения ... это было просто дополнительной вещью, которую, как я думал, читатели, которые приходят сюда, должны прочитать.
MicroservicesOnDDD
6

Также обратите внимание, что при использовании MFC, например, проекты отладки связываются с нераспространяемыми версиями DLL, например, в MFC90D.DLLто время как сборки выпуска ссылаются на распространяемые версии, такие как MFC90.DLL. Вероятно, это похоже на другие фреймворки.

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

foraidt
источник
очень верно. Один раз столкнулся с этим, когда был у клиента. Работает на моей машине (TM).
Мэтт Якобсен,
Вы можете их распространять ... (не знаю, можно ли). Они должны находиться в подпапке с соответствующими именами вашего приложения.
Андреас Рейфф
@Andreas Что касается моего примера, "нераспространяемые" означает, что Microsoft не разрешает их распространение.
foraidt
4

Меня тоже заинтересовал этот вопрос, когда я разработал приложение, скопированное из существующей конфигурации сборки Release.

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

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

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

Пустые VCXPROJs Debug vs Release diff

РЕЛИЗ

<PropertyGroup>
    <WholeProgramOptimization>true</WholeProgramOptimization>

<ClCompile>
    <Optimization>MaxSpeed</Optimization>
    <FunctionLevelLinking>true</FunctionLevelLinking>
    <IntrinsicFunctions>true</IntrinsicFunctions>
<Link>
    <EnableCOMDATFolding>true</EnableCOMDATFolding>
    <OptimizeReferences>true</OptimizeReferences>

ОТЛАЖИВАТЬ

<PropertyGroup>
    <UseDebugLibraries>true</UseDebugLibraries>`

<ClCompile>
    <Optimization>Disabled</Optimization>

Интересно, что в разделе Link они оба GenerateDebugInformationустановили значение true.

Jxramos
источник
3

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

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

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

fasih.rana
источник
-15

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

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

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

f470071
источник
7
Как это отвечает на вопрос? И обратите внимание, когда вы печатаете.
mmking
У меня была аналогичная проблема, код работает в режиме отладки, но есть проблема в режиме выпуска. Оказывается, проблема в моем коде. Есть отличная статья о типичных проблемах в релизной версии. Надеюсь, это поможет и другим.
Weihui Guo