Возможный дубликат отладки Visual Studio Release в .NET
В чем разница между отладкой и выпуском в Visual Studio?
Возможный дубликат отладки Visual Studio Release в .NET
В чем разница между отладкой и выпуском в Visual Studio?
Ответы:
Самое главное, что в режиме Debug оптимизаций нет, а в режиме Release есть оптимизации. Это важно, потому что компилятор очень продвинутый и может выполнять довольно сложные низкоуровневые улучшения вашего кода. В результате некоторые строки вашего кода могут остаться вообще без каких-либо инструкций, а некоторые могут быть перепутаны. Пошаговая отладка была бы невозможна. Кроме того, локальные переменные часто оптимизируются таинственным образом, поэтому часы и быстрые часы часто не работают, потому что переменная «оптимизирована». И есть множество других оптимизаций. Попробуйте как-нибудь отладить оптимизированный код .NET, и вы увидите.
Еще одно ключевое отличие состоит в том, что из-за этого настройки выпуска по умолчанию не беспокоятся о создании обширной информации о символах отладки. Это файл .PDB, который вы могли заметить, и он позволяет отладчику выяснить, какие инструкции сборки соответствуют какой строке кода и т. Д.
«Отладка» и «Выпуск» - это на самом деле всего лишь две метки для целого ряда настроек, которые могут повлиять на вашу сборку и отладку.
В режиме «Отладка» у вас обычно есть следующее:
В режиме «Release» оптимизации включены (хотя есть несколько доступных опций), и определение препроцессора _DEBUG не определено. Обычно вы все равно захотите сгенерировать файлы PDB, потому что очень полезно иметь возможность «отлаживать» в режиме выпуска, когда что-то работает быстрее.
В основном отладка включает много дополнительной информации, полезной при отладке. В режиме выпуска все это сокращается и обменивается на производительность.
Если вы просмотрите параметры компиляции проекта и сравните их, вы увидите, в чем различия.
Предполагая, что вопрос касается нативного кода / кода C ++ (это не совсем понятно из формулировки):
По сути, в Debug все оптимизации генерации кода отключены. Некоторые библиотеки (например, STL ) по умолчанию используют более строгую проверку ошибок (например, итераторы отладки). Создается дополнительная отладочная информация (например, для «Редактировать и продолжить»). В коде создается больше вещей для обнаружения ошибок (значения локальных переменных устанавливаются на неинициализированный шаблон, и используется куча отладки).
Кроме того, очевидно, что режим отладки создает множество дополнительных потоков, помогающих с отладкой. Они остаются активными на протяжении всего процесса, независимо от того, подключаете ли вы отладчик или нет. См. Мой связанный с этим вопрос здесь .
Вероятно, стоит упомянуть очень очевидное, что флаги сборки допускают различную логику, которая должна использоваться только для изменения ведения журнала и «консольного» обмена сообщениями, но ею можно злоупотреблять и кардинально изменить не только нижние уровни, но и реальную бизнес-логику.
Также обратите внимание, что при использовании MFC, например, проекты отладки связываются с нераспространяемыми версиями DLL, например, в MFC90D.DLL
то время как сборки выпуска ссылаются на распространяемые версии, такие как MFC90.DLL
. Вероятно, это похоже на другие фреймворки.
Поэтому вы, вероятно, не сможете запускать приложения для отладки на машинах, не предназначенных для разработки.
Меня тоже заинтересовал этот вопрос, когда я разработал приложение, скопированное из существующей конфигурации сборки Release.
У меня есть разработчик, которому интересно использовать это приложение в режиме отладки, поэтому я подумал, что нужно сделать, чтобы эта конфигурация сборки, существующая с именем ReleaseMyBuild, скопирована из конфигурации выпуска (и, следовательно, должна иметь все настройки, предназначенные для оптимизации выпуска. ), чтобы внезапно сменить команду и стать отладочной сборкой, несмотря на запутанное имя конфигурации сборки.
Я решил, что конфигурация проекта - это просто название и удобный способ выбрать «все множество настроек», о которых упоминает Йорис Тиммерманс. Я хотел знать в деталях, какие именно настройки могут быть, что делает конфигурацию сборки с именем «FOO» функцией оптимизированной сборки выпуска .
Вот один взгляд на это. Я создал новый VCXPROJ из пустого шаблона проекта из Visual Studio 2010. Затем я скопировал его и отредактировал оба: первый для сохранения содержимого отладки, а второй - содержимое выпуска. Вот разница, основанная на соответствующих различиях ...
РЕЛИЗ
<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.
Очевидная разница, которую вы можете увидеть, - это размер двоичного файла. Сборка отладки создает двоичный файл большего размера, чем сборка выпуска.
При компиляции в Debug таблица символов добавляется к скомпилированному объекту файла кода, что позволяет программам отладки подключаться к этим двоичным файлам и получать доступ к значениям объектов и переменных.
Еще одно заметное отличие состоит в том, что в режиме выпуска двоичный файл просто вылетает из-за фатальной ошибки, а в режиме отладки, если вы начнете отладку приложения в Visual Studio, вы можете проверить стек вызовов, который сообщает вам точное местоположение ошибочного оператора. .
Я не знаю, каковы точные различия, потому что на самом деле нет легко доступной информации по этому поводу.
Но основное наблюдаемое различие заключается в том, что релизная версия иногда повреждает итоговый файл DLL и, таким образом, делает ваше приложение, веб-приложение непригодным для использования.
К сожалению, вам нужно запустить отладочную сборку в производство. И да, для публикации нужно использовать старый добрый FTP.