Как мне использовать режим отладки / выпуска в Visual Studio?

Question

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

Редактировать: Спасибо за ответы. Похоже, это хорошая идея использовать режим отладки только на моей машине. Несмотря на то, что он находится в разработке, он в основном публикуется для публики (сотрудники, qa), поэтому он должен быть в режиме релиза. И, конечно же, это должен быть режим релиза при выпуске на prod.

Answer 1

При выпуске / публикации приложения вы должны делать это в режиме выпуска. Режим релиза предназначен только для этого, выпуская приложения. Созданный код, как правило, более производительный, и многие удаляют множество проверок, которые в большей степени связаны с фазой разработки приложения.

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

Тем не менее, вы также должны провести значимое тестирование режима Release как часть вашего процесса разработки. Клиенты будут видеть только версию вашего продукта в режиме выпуска, и ошибки могут зависеть от режима отладки / выпуска. Проверки ошибок, вставленные в режиме отладки, могут вызвать побочные эффекты, которые скрывают реальные ошибки в вашем приложении.

Answer 2

Я придерживаюсь этого подхода:

• код / ​​цикл отладки на моей рабочей станции: DEBUG
• выполнение юнит-тестов на моей рабочей станции: DEBUG
• профилирование на моей рабочей станции: RELEASE
• ночная сборка и автоматические тесты: RELEASE (выполняет автоматическую установку)
• практическое тестирование командой QA: RELEASE

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

Answer 3

В общем, ВСЕГДА развертывайте релизные сборки в производство. Отладка увеличит вес сборки и снизит производительность.

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

Что касается того, какую сборку развернуть в разработке ... если вы запускаете модульные тесты против разработки, вероятно, будет хорошей идеей развернуть сборку Debug, чтобы вы могли получить наибольшую отладочную информацию при сбое тестов или возникновении исключений. Однако, есть надежда, что существует дополнительная среда тестирования или подготовки к работе, в которой вы можете запустить интеграционные тесты и выполнить ручные тесты. Эта среда Testing / Pre-Prod ОБЯЗАТЕЛЬНО должна использовать сборки Release, чтобы вы могли увидеть истинные проблемы с производительностью и компиляцией перед переходом в Production.

Если у вас нет этого промежуточного уровня Testing / Pre-Prod, то я бы предложил запустить вашу среду разработки с Release. Другими словами, вы должны запустить хотя бы один уровень перед производством в конфигурации выпуска.

Для получения дополнительной информации о том, что вы можете сделать с конфигурациями, у меня есть пост в блоге специально для Silverlight (http://blog.tonyheupel.com/2009/04/environment-specific-service-references.html).). Там есть ссылка на более общую статью Скотта Хансельмана о конфигурациях сборки и различных средах.

Answer 4

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

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

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