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

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

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


visual-studio build-process
person Hertanto Lie    schedule 11.07.2009    source источник

Ответы (4)


arrow_upward
13
arrow_downward

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

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

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

person JaredPar    schedule 11.07.2009
comment
@JaredPar Проверка ошибок, вставленная в режиме отладки, может привести к побочным эффектам, которые скрывают настоящие ошибки в вашем приложении. -- Можно поподробнее? - person TGnat; 11.07.2009
comment
@TGnat, есть очевидные случаи, когда проверки изменяют глобальное состояние (зло, но существуют). Более тонкий аспект заключается в том, что простой запуск проверки изменяет время выполнения вашего приложения. Я видел много проблем с потоками, когда дорогие проверки в режиме отладки скрывали основные проблемы с синхронизацией, заставляя один поток работать дольше в режиме DEBUG, чем в режиме RELEASE. Это позволило другим потокам достичь завершенного состояния и придать вид работающего приложения. Как только проверка была удалена в режиме RELEASE, поток работал быстрее и выявлял состояние гонки. - person JaredPar; 11.07.2009

arrow_upward
8
arrow_downward

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

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

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

person Daniel Earwicker    schedule 11.07.2009

arrow_upward
3
arrow_downward

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

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

Что касается того, какую сборку развернуть для разработки... если вы запускаете модульные тесты для разработки, вероятно, будет хорошей идеей развернуть сборку отладки, чтобы вы могли получить максимальную отладочную информацию при сбое тестов или возникновении исключений. Тем не менее, есть надежда, что есть дополнительная среда тестирования или подготовки к производству, в которой вы можете запускать свои интеграционные тесты и выполнять ручные тесты. В этой тестовой/предварительной среде ОБЯЗАТЕЛЬНО должны использоваться выпускные сборки, чтобы вы могли увидеть истинные проблемы с производительностью и компиляцией, прежде чем переходить к производству.

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

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

person Tony Heupel    schedule 11.07.2009

arrow_upward
2
arrow_downward

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

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

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

person John Källén    schedule 11.07.2009