Что-то не так с выпуском программного обеспечения в режиме отладки?

Question

Мы все знаем, что «Режим отладки» следует использовать для разработки, потому что компилятор производит больше информации об отладке, а «Режим выпуска» следует использовать для производственных выпусков, потому что компилятор создает оптимизированный код.

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

Есть ли еще веские причины для выпуска программного обеспечения в режиме выпуска в этом случае?

Answer 1

Две проблемы, о которых я могу думать:

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

2. В отладочных сборках происходят странные вещи. Однажды я работал над долго работающим приложением, которое зависало примерно каждые двадцать дней. Оказывается, во время выполнения C счетчик (используемый для помощи в отладке) увеличивался при каждом выполнении malloc / free. Если счетчик переполнен - ​​kaboom! Только по этой причине я бы никому не рекомендовал развертывать двоичные файлы отладки - вы просто никогда не знаете, какие сюрпризы могут ожидать вашего клиента.

Answer 2

Возможные причины:

1. Отладка обычно не компилируется для производительности
2. Размер отладочного приложения (обычно) намного больше, чем при компиляции релиза.
3. Если кто-то попытается перепроектировать ваше приложение (по какой-либо причине), тогда это станет намного проще.

UPDATE: 4. Как уже указывалось, производительность компоновщика, но я бы подумал, будет далеко внизу списка: p Сколько раз вы выпускаете продукт по сравнению с отладочными компиляциями?

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

Answer 3

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

Answer 4

Я полагаю, что существует намного больше установленного отладочного кода, чем мы (разработчики) готовы признать.

Лично мне известно о многих производственных системах, которые развертываются на клиентах с кодом, скомпилированным в режиме отладки.

Answer 5

У меня нет никаких личных возражений против внутренней доставки сборки Debug, при условии, что она работает (некоторые версии Debug не будут работать на машинах не-dev без установки и соответствующих библиотек отладки ... Я запрограммировал код C ++ / MFC).

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

Если вы отлаживали проблему с компьютера клиента, укажите облегченный отладчик на свой сервер символов (убедитесь, что версии совпадают), а затем начните отладку.

Answer 6

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

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

Answer 7

У меня есть смутное воспоминание о том, что если вы берете двоичные файлы, скомпилированные в Debug, на компьютер, на котором не установлены библиотеки среды выполнения debug C (что обычно означает, что у него нет IDE, поэтому большинство пользователей попадают в эту категорию) , это будет barf с сообщением об ошибке. Я не знаю, относится ли это к Windows и / или C ++. Я также, возможно, запоминаю ... но вам непременно следует проверить, не произойдет ли это, так как если я прав, это будет основной причиной для компиляции в режиме выпуска.

Answer 8

дополнительная информация об отладке облегчает дальнейшее обслуживание.

Это зависит от того, что вы подразумеваете под «дополнительной информацией отладки».

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

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

Answer 9

У меня в основном две проблемы с релизом отладки:

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

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

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

Вы все еще можете собирать ценную информацию в версии выпуска. Трассировка стека все еще должна быть доступна в случае исключений. Вы можете не видеть исходный файл и номера строк, но вы все равно можете видеть, какие методы вызываются. Однако вы все равно должны создавать и хранить символы отладки для вашей сборки выпуска. Эти символы позволят вам отладить вашу версию выпуска (вы даже можете настроить сервер символов). Из-за оптимизации кода отладочная информация, скорее всего, не будет соответствовать 100% кода, например отладочная информация, относящаяся к оптимизированному оператору и т. д., но вы все равно должны быть в состоянии отладить большую часть его, хорошо. Другая информация, такая как вводимые пользователем данные, промежуточные данные, выполненный код базы данных и т. Д. Отладочный выпуск не поможет вам, так как он не собирает эту информацию. Вы должны следить за ними самостоятельно.

Если вы используете .NET, вы можете взглянуть на Tracing and Instrumentation . Вы также можете рассмотреть возможность использования существующей платформы, такой как Microsoft Enterprise Library или log4net. Если это приложение .NET, вы также можете запросить JIT-компилятор для создания информации отслеживания для версии выпуска вашего приложения в качестве опции. Ознакомьтесь с этой статьей MSDN .

Answer 10

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

• Гораздо быстрее и стабильнее
• Оптимизировано для машины
• Меньше по размеру
• Более безопасный (сложнее декомпилировать / взломать)
• Более эффективный и простой на оборудовании

Если у вас есть опция режима выпуска, почему бы не использовать ее? У вас всегда будет отладочная версия для разработки, или, если что-то пойдет не так, и вы всегда можете упаковать приложение и / или исходный код, созданный в Debug, в свою версию, собранную в выпуске.

Кроме того, у вас также может быть возможность создания приложения для определенных платформ. Компиляция с использованием режима Release упростит приложение для указанной платформы, сделав его гораздо более стабильным.

Даже если скорость не является проблемой, нет причин не использовать режим Release при компиляции.