Яка різниця між налагодженням та випуском у Visual Studio?

Можливий дублікат випуску налагодження Visual Studio Release у .NET

Яка різниця між налагодженням та випуском у Visual Studio?

Найголовніше, що в режимі налагодження немає оптимізацій, тоді як в режимі випуску - оптимізації. Це важливо, оскільки компілятор дуже просунутий і може зробити досить складне поліпшення вашого коду на низькому рівні. Внаслідок цього деякі рядки вашого коду можуть залишитися без будь-яких інструкцій, а в деяких - все змішатись. Поетапна налагодження була б неможливою. Крім того, локальні змінні часто оптимізуються таємничими способами, тому годинники та QuickWatches часто не працюють, оскільки змінна "оптимізована". І є безліч інших оптимізацій. Спробуйте де-який час налагодити оптимізований код .NET, і ви побачите.

Ще одна ключова відмінність полягає в тому, що через це налаштування випуску за замовчуванням не турбуються з генерацією великої інформації про символи налагодження. Це файл .PDB, який ви могли помітити, і він дозволяє налагоджувачу визначити, які вказівки щодо збірки відповідають виправленому рядку коду та ін.

"Налагодження" та "Випуск" - це фактично дві мітки для цілого ряду налаштувань, які можуть вплинути на вашу збірку та налагодження.

У режимі "Налагодження" у вас зазвичай є такі:

• Файли баз даних налагодження програми, які дозволяють досить уважно стежити за виконанням програми у джерелі під час виконання.
• Усі оптимізації вимкнено, що дозволяє перевіряти значення змінних та відстежувати функції, які в іншому випадку можуть бути оптимізовані за винятком або вбудованими
• Визначення препроцесора _DEBUG, яке дозволяє писати код, який діє в режимі налагодження по-різному порівняно з випуском, наприклад, на інструменти ASSERT, які слід використовувати лише під час налагодження
• Посилання на бібліотеки, які також були складені з параметрами налагодження, які, як правило, не розгорнуті для реальних клієнтів (з міркувань розміру та безпеки)

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

Переважно, налагодження включає багато додаткової інформації, корисної при налагодженні. У режимі випуску це все скорочення та торгується для продуктивності.

Якщо ви переглянете варіанти компіляції проектів і порівняєте їх, ви побачите, у чому полягають відмінності.

Припустимо, що питання стосується нативного / C ++ коду (це не зовсім зрозуміло з фразоутворення):

В основному, у налагодженні всі оптимізації генерації коду вимкнено. У деяких бібліотеках (наприклад, STL ) за замовчуванням відбувається більш сувора перевірка помилок (наприклад, ітератори налагодження). Створюється більше інформації про налагодження (наприклад, для "Редагувати та продовжувати"). У коді генерується більше речей для лову помилок (місцеві значення змінних встановлюються на неініціалізований візерунок, і використовується купа налагодження).

Також, мабуть, режим налагодження створює безліч зайвих потоків, щоб допомогти з налагодженням. Вони залишаються активними протягом усього життя процесу, незалежно від того, додаєте ви відладчик чи ні. Дивіться моє відповідне питання тут .

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

Також зауважте, що при використанні MFC, наприклад, проекти налагодження посилаються на неперерозподілювані версії DLL, наприклад, в MFC90D.DLLтой час, як версія будує посилання проти перерозподілюваних версій, як MFC90.DLL. Це, мабуть, схоже на інші рамки.

Тому ви, ймовірно, не зможете запускати програми налагодження програм на машинах, що не розробляють.

Мене цікавить і це питання, коли я розробив програму, скопійовану з існуючої конфігурації збірки версій.

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

Я подумав, що конфігурація проекту - це лише ім'я та зручний спосіб вибору "цілого ряду налаштувань", про який згадує Йоріс Тіммерманс. Я хотів би знати суворі будні тільки те , що ці параметри можуть бути, що вносять конфігураціями збірки з ім'ям функція «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>

Цікаво, що в розділі Посилання вони обоє GenerateDebugInformationвстановили істину.

Очевидна різниця, яку ви можете бачити, - це розмір двійкового файлу. Збірка налагодження створює більший двійковий файл, ніж збірка Release.

Під час компіляції у налагодженні таблиця символів додається до компільованого об’єкта файлу коду, що дозволяє програмам налагодження вписуватись у ці бінарні файли та отримувати доступ до значень об’єктів та змінних.

Ще одна помітна відмінність полягає в тому, що в режимі випуску бінарний файл буде просто збій на фатальну помилку в режимі налагодження. Якщо ви почнете налагодження програми в Visual Studio, ви можете перевірити стек виклику, який повідомляє вам точне місце помилкового твердження .

Я не знаю, в чому полягають точні відмінності, тому що насправді про це легко немає інформації.

Але головна відмічена відмінність полягає в тому, що версія релізу іноді пошкоджує отриманий файл DLL і, таким чином, робить ваш додаток, веб-додаток непридатним.

На жаль, вам доведеться налагоджувати налагодження у виробництві. І так, для публікації ви повинні використовувати старий добрий FTP.