Чем отличается отладочная сборка, запускаемая с отладкой и без отладки?
Раньше я считал, что если у нас есть сборка Debug , не имеет значения:
- Мы запустили это.
- Или мы это отладили.
Все было бы так же.
Однако недавно я столкнулся с двумя разными проблемами, из которых ясно, что что-то другое, когда код просто запускается или когда он отлаживается, даже если версия кода предположительно одинакова. (а именно Свободный NHibernate не удается загрузить MySql.Data из GAC в режиме отладки теста и Npgsql — указанный метод не поддерживается)
Мне интересно, в чем разница между этими двумя в .NET 4.0? Понимание различий, вероятно, может помочь мне решить возникающие у меня проблемы, потому что я, по крайней мере, знаю, где искать возможные причины ошибок в этих разных случаях. Я не понимаю этого, когда я запускаю модульные тесты, они все зеленые, но когда я пытаюсь их отладить, я получаю различные исключения .
4 ответа
Лучшее оружие для решения проблем сборки — fuslogvw. exe, он показывает, где он искал сборку и какая конфигурация используется, чтобы сообщить CLR, где найти сборку.
Существует вторичный режим отказа для тех сборок, с которыми у вас возникли проблемы. Эти поставщики баз данных часто являются управляемыми оболочками, которые для выполнения работы полагаются на неуправляемые библиотеки DLL. Windows должна быть в состоянии найти эти библиотеки DLL. Это имеет тенденцию к сбою, если они не копируются в каталог, который находится в PATH, или не копируется в ту же папку, что и основной EXE. Внимательно прочтите инструкции по развертыванию этих оболочек.
Есть несколько проблем, которых следует опасаться.
1) Как говорит codeninja, порядок операций может быть другим, если вы нарушите код.
2) Файлы могут находиться в разных местах, и пути могут по-разному разрешаться. Это очень важно, если у вас есть динамически загружаемые ресурсы или когда библиотеки DLL создаются и копируются в каталог подключаемого модуля. При отладке вы можете случайно загрузить не тот.
3) Наблюдение за переменными в отладчике может вызвать оценку. Представьте себе свойство, которое глупо увеличило свое поле поддержки, а затем вернуло увеличенное значение.
Разница в том, что когда отладчик подключен, он может останавливаться, когда генерируются исключения, которые в противном случае были бы перехвачены.
Параметры «Прерывание, когда исключения пересекают домен приложения или управляемые / собственные границы (только управляемые)» и «Включить только мой код» в Инструменты / Параметры / Отладка, а также параметры в Отладка / Исключения . определяют, какие исключения будет выполнять ваш отладчик. ломается при броске.
При отладке время выполнения кода будет немного другим, тем более, если вы слишком долго сидите внутри функций. Так что, если код чувствителен ко времени, вы можете столкнуться со странными ошибками. Это все, о чем я могу думать.
Почему я должен использовать отладочную сборку?
Почему я должен использовать конфигурацию отладки в приложениях Android?
Причина моего вопроса в том, что я столкнулся с некоторыми ошибками, которые можно было бы полностью избежать, если бы я всегда отлаживал свой код в релизном варианте.
Поэтому в релизной сборке я просто установил флаг debuggable в true и отключил ProGuard на время отладки. -> Проблема исчезла.
(Конечно, мне все еще нужно протестировать один раз с включенным ProGuard. )
Есть ли аргументы против моего подхода? Если нет, то зачем тогда существует отладочная сборка?
Подборка аргументов в пользу отладочного варианта согласно другим ответам:
- ProGuard (хорошо. это не аргумент)
- скорость сборки (почему-то мой релизный вариант занимает меньше времени на компиляцию. )
- API-ключи (один пользователь более или менее не имеет значения. )
- отлаживаемость (это также работает в релизной сборке)
- разрешения только для отладки (я могу не комментировать эту строчку в манифесте. )
- сертификат подписи (это не имеет значения. )
Пожалуйста, дайте мне что-нибудь, что заставит меня использовать отладочный вариант, иначе я запрещу его в своих приложениях^^.
В небольших проектах отладочная сборка может показаться излишеством. Как указано в комментариях, это точно такая же сборка, как и сборка релиза, если вы включите proguard и включите отладку. Это просто шаблон для проекта Android, который позволяет быстро настроить два типа сборок.
Когда вы работаете над более крупными проектами, эта функциональность становится более интересной. Вы настроите сервер сборки, который будет запускать автоматические сборки на регулярной основе, так что вам не придется вручную настраивать файл gradle каждый раз, когда вам нужен определенный тип сборки. Помимо debug и release вы, возможно, захотите создать еще несколько конфигураций, каждая из которых будет подключаться к различным тестовым средам, чтобы тестировщики могли работать без необходимости обращаться к вам каждый раз, когда им нужна другая сборка. Вы также упоминаете, что время сборки будет короче при выпуске, но когда ваш проект станет большим и вы включите, например, Dexguard для обфускации, это займет очень много времени каждый раз, когда вы захотите собрать сборку, и вам понравится иметь отладочные сборки для ускорения разработки.
Отладочная сборка
Существует версия Windows, называемая отладочной сборкой (checked build), которая доступна только подписчикам MSDN Operating Systems. Это пере компилированный исходный код Windows с выставленным флажком времени компиляции DBG (включает условный код отладки и трассировки). Кроме того, чтобы было проще понять машинный код, не производится последующая обработка двоичных кодов Windows, оптимизирующая расположение кода для быстрого выполнения. (См. раздел «Debugging Performance-Optimized Code» в файле справки Debugging Tools for Windows.) В первую очередь отладочная сборка предназначена для помощи разработчикам драйверов устройств, потому что в ней выполняются более строгие проверки на наличие ошибок в функциях режима ядра, вызываемых драйверами устройств или другим системным кодом. Например, если драйвер (или какой-нибудь другой фрагмент кода, выполняемого в режиме ядра) осуществляет неверный вызов системной функции, которая ведет проверку аргументов (например, запрос спин-блокировки на неправильном уровне прерывания), система при обнаружении проблемы останавливает выполнение, не допуская разрушения какой-нибудь структуры данных и возможной в последующем аварии системы.