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

Ответ 1

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

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

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

Ответ 2

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

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

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

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

Ответ 3

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

Ответ 4

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

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

Ответ 5

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

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

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

Ответ 6

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

Ответ 7

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

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

Ответ 8

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

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

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

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

Ответ 9

Зависит от пользователя

Если пользователь является техническим, предоставление дополнительного отладочного пакета для символов может помочь им отлаживать от вашего имени или отправлять дополнительную техническую информацию об ошибках... экономя ваши деньги/время > .

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

Если это бизнес, ища скудную машину без вздутия, то дайте им ободранную версию.

В зависимости от того, где ваши цели и ограничения для бизнеса/связи.

Ответ 10

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

1) Компиляция страниц ASP.NET занимает больше времени (поскольку некоторые оптимизации пакетов отключены)

2) Код может выполняться медленнее (поскольку разрешены некоторые дополнительные пути отладки)

3) В приложении во время выполнения используется гораздо больше памяти

4) Скрипты и изображения, загруженные из обработчика WebResources.axd, не кэшируются

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

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

Ответ 11

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

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

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

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

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

Ответ 12

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

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

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

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

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

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

Ответ 13

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

Ответ 14

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

Ответ 15

Мое дерево решений выглядит следующим образом:

Является ли программа написанной на Java?

Да. Тогда отпустите в режиме отладки. JIT позаботится об оптимизации

В противном случае - интенсивна ли программа CPU?

Нет - освобождение в режиме отладки прекрасное.

Да. Затем скомпилируйте только горячую точку в режиме деблокирования.

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

Ответ 16

Вы выпускаете программное обеспечение? (Это вопрос "Да", "Нет", "Да, но..." не учитывается)

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

Ответ 17

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

Иногда оптимизатор вызывает ошибки, иногда он скрывает их, но по крайней мере у вас есть возможность сузить проблему. Это помогло мне в условиях Blackbox, таких как Raytheon, где получение дампа ядра было невозможно, а трассировка стека была отправлена ​​по факсу с большим черным маркером по всему миру.

Ответ 18

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

Безопасность: Отладочная сборка и отладочная информация (например, файлы pdb) содержат большую информацию об исходном коде, которая не только упрощает декомпиляцию, но также позволяет пользователям знать внутренние данные, такие как имена файлов и сетевые пути. Многие компании могут считать эту информацию очень чувствительной.

Ответ 19

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

Но в зависимости от чувствительной блокировки данных отладочная версия отсутствует.

Ответ 20

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

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