Возможный дубликат отладки 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.