Есть ли необходимость отладочной сборки в .net?

Question

Если в выпускной версии создаются файлы .pdb, и вы можете переходить к каждой строке, ставить точки останова и т. Д., Зачем вообще создавать «отладочную» версию моих компонентов?

Я использую c # для своих проектов, и у меня не было проблем с отладкой релизных версий. В C ++ у меня были проблемы с отладкой оптимизированного кода, но в C # он работает нормально. Я не говорю о глупых блоках кода, таких как if(false) ...

Answer 1

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

Answer 2

Одна из причин - присоединение или запуск.

Если вы запускаете процесс Retail в .Net, отладка почти так же хороша, как запуск процесса отладки. Скорее всего, вы не заметите никакой разницы в вашем опыте отладки.

Attach - совершенно другая игра с мячом. И C #, и VB проходят флаг / optimize + для розничных сборок. Это будет включать DebuggableAttribute на уровне сборки без флага DebuggingMode.DisableOptimizations. Во время запуска процесса VS / CLR будет связываться, чтобы по существу игнорировать этот факт и отключить JIT-оптимизацию, которая влияет на отладку. Во время присоединения такого элемента не происходит, и JIT / CLR оптимизируется под его содержание. Я гарантирую вам, опыт отладки намного хуже в этом случае.

Вы можете поэкспериментировать с этим в VS

• Переключить сборку в Release
• CTRL + F5 для запуска без отладки
• Присоединить к процессу.

Answer 3

В (c #) winforms вы не можете редактировать и продолжить в сборках релиза ..

Answer 4

Помимо других ответов, я использую автоматически сгенерированный #define DEBUG для изменения поведения при возникновении необработанного исключения:

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

Answer 5

Есть несколько причин:

• По умолчанию сборка выпуска не содержит столько отладочной информации в файле PDB. Я полагаю, что опция для этого раньше была более заметной - теперь она находится в «Расширенных настройках» в разделе «Вывод» с возможными значениями «none», «full» (по умолчанию для отладочных сборок) и «pdb-only» (по умолчанию для выпуска строит).
• По умолчанию сборка релиза оптимизирована: хотя это не имеет такого большого значения в C #, как в других языках (например, C ++), поскольку JIT выполняет большую часть работы, вполне может быть some различий, которые затрудняют отладку сборки выпуска.
• По умолчанию сборка выпуска не определяет символ DEBUG, поэтому любые вызовы Debug.Assert и т. Д. Будут удалены.

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

Answer 6

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

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

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

Answer 7

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

Answer 8

Выпуски сборки выполняют дополнительную оптимизацию по сравнению с отладочными сборками, однако сборка отладки также немного меняет поведение GC, чтобы гарантировать, что вы не получите объект, извлеченный из-под себя, пока вы находитесь в середине сеанса отладки. Сборки отладки также предотвращают определенные оптимизации во время JIT, что отрицательно скажется на вашем сеансе отладки.