Развертывание приложения в производство с использованием режима отладки, а не режима выпуска?

Question

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

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

Какие-нибудь серьезные красные флажки, которые мешали бы вам делать это?Мне поручено исследовать возможность.Так что спасибо за любой отзыв.

Answer 1

Развертывание вашего приложения в режиме DEBUG вместо режима Release замедлит вашу производительность. Конечно, компромиссы могут быть сделаны. Я бы предложил одно из следующего:

• Посмотрите, как добавить глобальный обработчик ошибок в OnError в вашем global.asax-
• Посмотрите на компромисс, похожий на этот , предложенный Скоттом Хансельманом

Answer 2

Вы отметили это [vb.net], вы не можете отправлять отладочные сборки или программы, которые используют WithEvents. Существует известная и нерешенная утечка памяти для экземпляров WeakReference, если отладчик не подключен. Они используются для поддержки редактирования + продолжения.

Первое, что вы можете сделать, это отправить файлы .pdb вместе с вашими приложениями. В C # IDE используйте Project + Properties, вкладку Build, Advanced, измените «Debug Info» на «Full». Вы получите информацию о номере строки в трассировке стека исключений.

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

[.NET Framework Debugging Control]
GenerateTrackingInfo=1
AllowOptimize=0

Answer 3

Мой опыт показывает, что это может работать нормально, если вы думаете о настольном (winforms / WPF) приложении, но ни при каких обстоятельствах не пытайтесь это сделать с приложением asp.net.

Answer 4

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

Answer 5

Развертывание отладочных сборок - это красный флаг для меня, хотя и не случайно.Это настольное или серверное приложение?Любые вызовы Debug.Assert , которые могут быть неудачными, могут быть проблемой, так как они могут завершить работу вашего приложения и / или привести к подключению отладчика (VS.NET - не единственный отладчик, и, если я помню, .net fx устанавливаетлегкий отладчик).Хотя это может быть полезно в качестве разработчика, это, безусловно, может сбить с толку обычного человека.

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

Answer 6

Все зависит от важности вашей производственной среды, требований бизнеса и производительности.Нет ничего строгого.