Приложение не поддерживает динамическую отладку форм Windows

Обновлено: 21.11.2024

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

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

Вы также можете отлаживать приложение, просматривая трассировку стека. Обычно это результат создания исключения или код, содержащий явные вызовы Console.WriteLine(Environment.StackTrace) . Это поможет вам понять, какие кадры вызовов были в точке трассировки стека, и вы можете использовать это, чтобы понять, что могло привести к конкретному состоянию, которое вы изучаете (сбой, исключение, отчет).

Отладчиков и трассировки стека недостаточно. Иногда вам нужно увидеть, что происходит во время работы приложения, «отследить» его выполнение и просмотреть передаваемые параметры и возвращаемые значения. Подробнее об этом методе см. в разделе "Отслеживание выполнения программы".

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

Отладочная информация

Чтобы получить трассировку стека с информацией о номере строки, вам нужно запустить программу следующим образом:

Обратите внимание, что программа должна быть скомпилирована с флагом -debug, а запуск с параметром –debug замедлит выполнение.

Отладка с помощью GDB

GDB можно использовать для получения некоторой информации о вашем приложении и устранения некоторых проблем. В этом разделе содержится подробная информация об отладке приложения Mono с помощью GDB.

Прежде всего, библиотеки поддержки Mono используют несколько внутренних сигналов, которые сбивают с толку gdb. Чтобы обойти это, поместите это в свой файл .gdbinit (в путь $HOME):

Если вы используете GDB для отладки своего монопроцесса, вы можете использовать функцию mono_print_method_from_ip (которая принимает адрес), чтобы получить имя метода по указанному адресу. Это особенно полезно при изучении трассировки стека. Функция была переименована в mono_pmip в серии Mono 1.1.x (некоторое время функция называлась mono_print_method_from_ip ).

Например, столкнувшись с трассировкой стека, вот так:

Вы можете узнать, какие методы находятся на каждом адресе, используя функцию mono_print_method_from_ip (или mono_pmip, если вы используете Mono 1.1.x):

Иногда вам может понадобиться создать полный дамп всех управляемых имен из gdb, это можно сделать с помощью макроса gdb. Поместите это в свой файл .gdbinit в вашем ДОМАШНЕМ каталоге:

Затем вы можете ввести «mono_backtrace 15» из командной строки gdb, чтобы получить трассировку последних 15 кадров.

Если вы часто используете P/Invoke, часто полезно установить точку останова в неуправляемой функции, а затем распечатать управляемую трассировку стека. Начиная с версии 1.1.13.4, вы можете добавить следующий макрос gdb в свой файл .gdbinit. (Обратите внимание, это было проверено только на x86):

Использование «mono_stack» из gdb напечатает управляемую трассировку стека в стандартный вывод программы. Он не будет распечатан в вашей консоли gdb! Вы также можете использовать «thread apply all mono_stack» для печати стеков для всех потоков.

Вывод будет выглядеть примерно так:

В версиях после Mono 1.1.18 доступно несколько новых функций, помогающих отлаживать приложения из GDB.

Используйте mono_object_describe, чтобы получить краткое описание объекта obj.

Используйте mono_object_describe_fields, чтобы получить краткое описание всех полей данного объекта.

Используйте mono_value_describe_fields для вывода на стандартный вывод небольшого описания каждого поля типа значения, хранящегося по адресу @addr типа @klass.

Используйте mono_class_describe_statics для вывода на стандартный вывод небольшого описания каждого статического поля типа @klass в текущем домене приложения.

Используйте mono_debug_print_vars для вывода на стандартный вывод информации о локальных переменных в методе (если @only_arguments имеет значение false) или об аргументах.

Информация включает информацию о хранении (где находится переменная, в регистре или в памяти). Метод можно найти, просматривая, какой метод был сгенерирован по адресу инструкции @ip.

Вот пример сеанса:

Отладка с помощью LLDB

Вы можете использовать следующий скрипт Python LLDB для получения следов в lldb: monobt.py

Предположим, что приведенный выше скрипт сохранен в ~/Library/lldb/monobt.py, вы можете загружать его автоматически в каждом сеансе lldb, поместив следующее в .lldbinit (в вашем каталоге $HOME):

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

Обычно вы будете отлаживать Mono после его самостоятельной сборки, но можно отладить готовый пакет Mono, используя средство target.source-map LLDB.

Известные ограничения

Если возникает ошибка сегментации ( EXC_BAD_ACCESS ), LLDB не может возобновить работу обработчика сигнала. К сожалению, это противоречит неявным проверкам null, используемым Mono. Обходные пути, пока это не будет исправлено:

  1. Запускайте моно с MONO_DEBUG=explicit-null-checks , чтобы среда выполнения не использовала указанный метод. С точки зрения производительности это немного медленнее, но для целей отладки это нормально.
  2. Используйте gdb. К сожалению, в наши дни для этого требуется доработать macOS.

Отладка с помощью Visual Studio в Windows

Большинство приемов, которые можно использовать в GDB, также можно использовать в Windows с помощью отладчика Visual Studio. Вы можете использовать Immediate Window для ввода ваших команд. если команда gdb:

эквивалентная команда для непосредственного окна та же самая без p и явного приведения аргумента к void*

Если моно было загружено из динамической библиотеки, а указанная выше команда не работает, вы можете более подробно указать Visual Studio, где найти эту функцию. Предполагая, что моно был загружен из «mono.dll», несколько загадочная команда выглядит так:

Отладка взаимоблокировок управляемых блокировок

Одним из явно неправильных способов использования блокировок является использование нескольких блокировок и получение их в разном порядке в разных кодовых путях. Вот пример:

Существует явный вызов Sleep(), чтобы состояние гонки возникало почти каждый раз, когда вы запускаете такую ​​программу. Проблема с такими взаимоблокировками заключается в том, что обычно окно времени гонки очень маленькое, и оно останется незамеченным во время тестирования. Новая функция среды выполнения mono предназначена для того, чтобы помочь найти проблему, когда процесс зависает, и мы не знаем, почему.

Теперь вы можете подключиться к зависшему процессу с помощью gdb и ввести следующую команду:

что приводит к следующему выводу:

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

В данном конкретном случае это довольно просто, поскольку объекты, используемые для блокировки, являются статическими полями. Самый простой способ получить класс — заметить, что объект, заблокированный дважды (0x2ffd8), относится к тому же классу, что и статические поля:

Теперь мы знаем класс (0x820922c) и можем получить список статических полей и их значений и соотнести с объектами, заблокированными в списке mono_locks_dump():

Обратите внимание, что объекты lockA и lockB перечислены выше как взаимоблокирующие.

Отладка неуправляемых взаимоблокировок

Если взаимоблокировка, с которой вы столкнулись, не вызвана вашим кодом, это может быть проблема среды выполнения Mono. Чтобы узнать это, выполните следующие действия:

  • Заблокируйте приложение.
  • Запустите gdb из командной строки.
  • Выполнить присоединение (чтобы найти процесс, выполните команду ps -A | grep mono ).
  • Выполнение потока применяет все bt .

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

Отладка закрепленных объектов

Mono GC будет консервативно сканировать часть стеков потоков, чтобы определить, ссылаются ли они на объекты, которые, таким образом, необходимо поддерживать в рабочем состоянии. Однако иногда стек содержит целые числа или другие данные, которые выглядят как указатель на объект, но на самом деле он не используется для хранения ссылки на управляемую память. При использовании SGen GC, чтобы помочь отладить эти случаи, вы можете вызвать функцию find_pinning_ref_from_thread(obj, obj_size), чтобы проверить, закрепляется ли объект obj из некоторых местоположений потока. Убедитесь, что у вас моно-отладочная сборка, так как компоновщик может оптимизировать эту функцию из производственных сборок.

Запуск отладчика

Из управляемого кода вы можете вызвать метод System.Diagnostics.Debugger.Break() в своем коде, чтобы прервать выполнение и перейти к подсказке GDB.

Из неуправляемого кода вы можете использовать макрос G_BREAKPOINT() в своем коде.

Отладка с помощью GDB в режиме XDEBUG

В версии mono 2.6 и более поздних версиях теперь можно запросить у среды выполнения создание отладочной информации, которую может использовать gdb. В настоящее время это работает только на amd64/x86/arm linux. Чтобы использовать его:

Для gdb 7.0

  • Настройка не требуется, gdb автоматически загрузит монофонический режим, написанный на python, а среда выполнения зарегистрирует отладочную информацию в gdb, используя новый интерфейс JIT в gdb 7.0.

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

Для старых версий gdb

  • Установите для переменной окружения MONO_XDEBUG значение «1».
  • Добавьте в свой .gdbinit следующее:
  • Запустите mono под gdb с параметром –debug (если вы хотите запустить moon, просто запустите «firefox -d gdb» или «firefox -g -d gdb», если вы используете Firefox > 3.5). Наличие файлов .mdb очень помогает.
  • Когда программа остановлена, введите «xdb». Это приведет к тому, что среда выполнения сгенерирует отладочную информацию, а gdb загрузит ее.

Теперь вывод будет выглядеть следующим образом:

Поддержка XDEBUG в моно смоделирована по образцу аналогичной функциональности в Kaffe.

Исключения

Иногда последовательности try/catch могут скрывать основные проблемы в вашем коде. Возможно, вы захотите просмотреть исключения, созданные вашей программой, с помощью средства трассировки Mono. Чтобы использовать это, попробуйте:

Это отобразит исключения, которые выдает ваша программа.

Если вы хотите узнать, где создаются эти исключения с помощью gdb, вы можете использовать следующий прием:

Для этого требуется установить Mono с символами. Затем вы можете проверить различные аспекты вашей программы:

Отслеживание выполнения программы

Трассировка позволяет разработчикам видеть, когда методы вводятся и выходят из них во время работы их приложения. Это включается путем передачи аргумента командной строки –trace в mono. Вывод может быть довольно подробным:

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

Приведенный выше пример ограничивает трассировку методами в пространстве имен MyApplication.

Или для отслеживания нескольких пространств имен:

Например, чтобы отслеживать пространство имен, но игнорировать некоторые типы:

Вы можете переключить вывод трассировки, отправив сигнал SIGUSR2 монопроцессу. Кроме того, вы можете запускать приложение с отключенным выводом трассировки до тех пор, пока ваше приложение не достигнет точки, которую вы хотите отладить:

Затем с другой консоли можно включить вывод:

Где `pid' — это идентификатор отслеживаемого процесса Mono.

Вы можете отключить вывод, повторно отправив процессу сигнал USR2.

Ведение журнала выполнения

Вы можете попросить среду выполнения записать различные сообщения в стандартный вывод, используя: MONO_LOG_LEVEL=debug

Использование Valgrind в Mono

Иногда бывает полезно запустить Mono с Valgrind для отслеживания проблем в приложении. Это особенно полезно при отладке проблем с библиотеками или привязками P/Invoked.

Исторически сложилось так, что Mono и Valgrind не всегда хорошо играли вместе. Если это обескуражило вас в прошлом, пришло время попробовать еще раз!

Последние версии valgrind могут работать с самомодифицирующимися программами (что и делает моно JIT) с помощью параметра –smc-check=all.

В качестве дополнительного бонуса Паоло (волчанка) поделился своим файлом подавления для Моно. Это удаляет много, но не все, ложных срабатываний (или неважных) журналов, поступающих из среды выполнения Mono. Это упрощает и ускоряет поиск того, что вы ищете. Файл подавления доступен в git Mono как /mono/data/mono.supp

libgdiplus

Cairo предоставляет собственный файл подавления, который полезно добавить, если ваше приложение зависит от System.Drawing (или System.Windows.Forms).

Файл находится в папке libgdiplus/cairo/test/.valgrind-suppressions и может использоваться одновременно с файлом, предоставленным для Mono.

Оперативная отладка может автоматически запускать Visual Studio, когда приложение, работающее за пределами Visual Studio, выдает ошибку или аварийно завершает работу. С помощью отладки Just-In-Time вы можете тестировать приложения вне Visual Studio и открывать Visual Studio, чтобы начать отладку при возникновении проблемы.

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

Если вы просто хотите, чтобы диалоговое окно JIT-отладчика не появлялось, но у вас не установлена ​​Visual Studio, см. раздел Отключение JIT-отладчика. Если у вас когда-то была установлена ​​Visual Studio, вам может потребоваться отключить отладку Just-In-Time в реестре Windows.

Включить или отключить оперативную отладку в Visual Studio

Чтобы включить или отключить оперативную отладку, вы должны запустить Visual Studio от имени администратора. Включение или отключение оперативной отладки устанавливает раздел реестра, и для изменения этого ключа могут потребоваться права администратора. Чтобы открыть Visual Studio от имени администратора, щелкните приложение Visual Studio правой кнопкой мыши и выберите Запуск от имени администратора.

Можно настроить оперативную отладку в диалоговом окне Инструменты Visual Studio > Параметры (или Отладка > Параметры).

Чтобы включить или отключить оперативную отладку:

В меню "Инструменты" или "Отладка" выберите "Параметры" > "Отладка" > "Точно вовремя".

В поле Включить отладку Just-In-Time для этих типов кода выберите типы кода, для которых требуется отладка Just-In-Time: Managed, Native и/или Script.

Выберите ОК.

Если вы включили отладчик Just-In-Time, но он не открывается при сбое или ошибке приложения, см. раздел Устранение неполадок при отладке Just-In-Time.

Отключить оперативную отладку из реестра Windows

Оперативная отладка может быть включена, даже если Visual Studio больше не установлена ​​на вашем компьютере. Если Visual Studio больше не установлена, вы можете отключить оперативную отладку, изменив реестр Windows.

Чтобы отключить оперативную отладку путем редактирования реестра:

В меню "Пуск" Windows запустите редактор реестра (regedit.exe).

В окне редактора реестра для 64-разрядных компьютеров найдите и удалите следующие записи реестра:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger

Если присутствуют следующие записи реестра или на вашем компьютере установлена ​​32-разрядная операционная система, удалите следующие записи:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger

Не удаляйте и не изменяйте другие разделы реестра.

Закройте окно редактора реестра.

Включить оперативную отладку формы Windows

По умолчанию приложения Windows Form имеют обработчик исключений верхнего уровня, который позволяет приложению продолжать работу, если оно может восстановиться. Если приложение Windows Forms выдает необработанное исключение, отображается следующее диалоговое окно:

Чтобы включить оперативную отладку вместо стандартной обработки ошибок Windows Form, добавьте следующие параметры:

В приложении C++ Windows Form также задайте для атрибута DebuggableAttribute значение true в файле .config или в коде. Если вы компилируете с /Zi и без /Og, компилятор устанавливает этот атрибут за вас. Однако, если вы хотите отладить неоптимизированную сборку выпуска, вы должны установить атрибут DebuggableAttribute, добавив следующую строку в файл AssemblyInfo.cpp вашего приложения:

Используйте оперативную отладку

В этом примере показано, как выполнять отладку Just-In-Time, когда приложение выдает ошибку.

Для выполнения этих действий у вас должна быть установлена ​​Visual Studio. Если у вас нет Visual Studio, вы можете загрузить бесплатную версию Visual Studio Community Edition.

Убедитесь, что отладка Just-In-Time включена в меню Инструменты > Параметры > Отладка > Just-In-Time.

Когда проект откроется в Visual Studio, откройте файл Program.cs. Замените метод Main() следующим кодом, который выводит строку на консоль, а затем создает исключение NullReferenceException:

Чтобы построить решение, выберите конфигурацию "Отладка" (по умолчанию) или "Выпуск", а затем выберите "Сборка" > "Перестроить решение".

  • Выберите конфигурацию отладки для полной отладки.
  • Если вы выберете Конфигурация выпуска, вы должны отключить Только мой код, чтобы эта процедура работала. В разделе "Инструменты" > "Параметры" > "Отладка" снимите флажок "Включить только мой код".

Дополнительную информацию о конфигурациях сборки см. в разделе Общие сведения о конфигурациях сборки.

Вы должны увидеть следующее командное окно:

Откроется диалоговое окно «Выберите своевременный отладчик».

В разделе "Доступные отладчики" выберите "Новый экземпляр", если он еще не выбран.

Выберите ОК.

Проект ThrowsNullException открывается в новом экземпляре Visual Studio, при этом выполнение останавливается на строке, вызвавшей исключение:

С этого момента вы можете начать отладку. Если бы вы отлаживали реальное приложение, вам нужно было бы выяснить, почему код выдает исключение.

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

Устранение неполадок при своевременной отладке

Если отладка Just-In-Time не запускается при сбое приложения, даже если она включена в Visual Studio:

Отчеты об ошибках Windows могут взять на себя обработку ошибок на вашем компьютере.

Чтобы устранить эту проблему, используйте редактор реестра, чтобы добавить параметр DWORD Disabled со значением 1 в следующие разделы реестра:

HKEY_LOCAL_MACHINE\Software\WOW6432Node\Microsoft\Windows\Отчеты об ошибках Windows

(Для 32-разрядных машин) HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Windows Error Reporting

Для получения дополнительной информации см. настройки .WER.

Известная проблема Windows может быть причиной сбоя JIT-отладчика.

Исправление заключается в добавлении значения DWORD Auto со значением данных 1 в следующие разделы реестра:

HKEY_LOCAL_MACHINE\Software\WOW6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug

(Для 32-разрядных машин) HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug

Во время отладки Just-In-Time вы можете увидеть следующие сообщения об ошибках:

Невозможно подключиться к аварийному процессу. Указанная программа не является программой Windows или MS-DOS.

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

Чтобы обойти эту проблему, в Visual Studio откройте "Отладка" > "Присоединить к процессу" (или нажмите Ctrl + Alt + P) и найдите процесс, который нужно отладить, в списке "Доступные процессы". Если вы не знаете имя процесса, найдите идентификатор процесса в диалоговом окне Just-In-Time Debugger Visual Studio. Выберите процесс в списке «Доступные процессы» и нажмите «Присоединить». Выберите Нет, чтобы закрыть диалоговое окно отладчика Just-In-Time.

Не удалось запустить отладчик, так как ни один пользователь не вошел в систему.

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

Чтобы решить эту проблему, войдите в систему.

Класс не зарегистрирован.

Отладчик попытался создать незарегистрированный COM-класс, вероятно, из-за проблемы с установкой.

Чтобы решить эту проблему, используйте установщик Visual Studio для переустановки или восстановления установки Visual Studio.

Обсудите и поддержите Как включить JIT-отладку? в настройке Windows 10 для решения проблемы; Пожалуйста, помогите мне, когда я открываю приложение, приложение не работает и показывает эту ошибку, пожалуйста, помогите решить ее. Смотрите конец этого. Обсуждение в разделе «Настройка Windows 10», начатое пользователем Aayanali4, 8 июня 2021 г.

Как включить JIT-отладку?

Как включить JIT-отладку? – Похожие темы – включить JIT-отладку

Как включить JIT-отладку

Как включить JIT-отладку: помогите мне, у меня возникает эта ошибка необработанного исключения при открытии переносимого приложения. Это полное сообщение об ошибке: подробности см. в конце этого сообщения. при вызове оперативной JIT-отладки вместо этого диалогового окна. ************** Текст исключения.

Как включить JIT-отладку

Как включить JIT-отладку: помогите мне, у меня возникает эта ошибка необработанного исключения при открытии переносимого приложения. Это полное сообщение об ошибке: подробности см. в конце этого сообщения. при вызове оперативной JIT-отладки вместо этого диалогового окна. ************** Текст исключения.

Как включить JIT-отладку

Как включить JIT-отладку: помогите мне, у меня возникает эта ошибка необработанного исключения при открытии переносимого приложения. Это полное сообщение об ошибке: подробности см. в конце этого сообщения. при вызове оперативной JIT-отладки вместо этого диалогового окна. ************** Текст исключения.

JIT-отладка

JIT-отладка. Ребята, мне нужна помощь с этой ошибкой. Это все сообщение об ошибке, было бы здорово, если бы кто-нибудь помог мне решить проблему! Спасибо легендам. -------------------------------------------------- ----------------------------------- Смотрите в конце этого сообщения.

ошибка отладки jit

Jit-отладка

Jit-отладка: кто-нибудь, пожалуйста, скажите мне, как исправить это для Windows 10, я не очень сообразителен. Подробнее см. в конце этого сообщения.

JIT-отладка

JIT Debugging: К сожалению, я только что понял, что поместил свой вопрос в строку темы. дух. Что вы все можете рассказать мне о JIT-отладке? Хочу ли я попытаться включить его, чтобы я мог видеть компакт-диск с компьютерной томографией, или я испорчу свой компьютер. эта программа не запускается автоматически, как другие, которые я рассматривал.

Архитектура отладки Visual Studio Code позволяет авторам расширений легко интегрировать существующие отладчики в VS Code, имея при этом общий пользовательский интерфейс со всеми ними.

VS Code поставляется с одним встроенным расширением отладчика, расширением отладчика Node.js, которое является отличной демонстрацией многих функций отладчика, поддерживаемых VS Code:

На этом снимке экрана показаны следующие функции отладки:

  1. Отладка управления конфигурацией.
  2. Действия отладки для запуска/остановки и пошагового выполнения.
  3. Исходные, функциональные, условные, встроенные точки останова и точки журнала.
  4. Трассировка стека, включая поддержку нескольких потоков и процессов.
  5. Навигация по сложным структурам данных в представлениях и при наведении курсора.
  6. Значения переменных отображаются при наведении указателя мыши или встроены в источник.
  7. Управление выражениями просмотра.
  8. Консоль отладки для интерактивной оценки с автозаполнением.

Эта документация поможет вам создать расширение отладчика, которое позволит любому отладчику работать с VS Code.

Архитектура отладки кода VS

VS Code реализует универсальный (не зависящий от языка) пользовательский интерфейс отладчика на основе абстрактного протокола, который мы представили для взаимодействия с серверными частями отладчика. Поскольку отладчики обычно не реализуют этот протокол, для «адаптации» отладчика к протоколу требуется некоторый посредник. Этот посредник обычно представляет собой автономный процесс, взаимодействующий с отладчиком.

Мы называем этого посредника адаптером отладки (сокращенно DA), а абстрактный протокол, который используется между DA и VS Code, называется протоколом адаптера отладки (сокращенно DAP). Поскольку протокол адаптера отладки не зависит от VS Code, у него есть собственный веб-сайт, на котором можно найти введение и обзор, подробную спецификацию и некоторые списки с известными реализациями и вспомогательными инструментами. История и мотивы DAP объясняются в этой записи блога.

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

По этой причине VS Code предоставляет точку добавления, отладчики , где адаптер отладки может быть предоставлен для определенного типа отладки (например, узел для отладчика Node.js). VS Code запускает зарегистрированный DA всякий раз, когда пользователь запускает сеанс отладки этого типа.

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

Более реалистичное расширение отладчика вносит в VS Code многие или все следующие декларативные элементы:

  • Список языков, поддерживаемых отладчиком. VS Code позволяет пользовательскому интерфейсу устанавливать точки останова для этих языков. упоминание — схема JSON для атрибутов конфигурации отладки, введенных отладчиком. VS Code использует эту схему для проверки конфигурации в редакторе launch.json и предоставляет IntelliSense. Обратите внимание, что конструкции схемы JSON $ref и определение не поддерживаются.
  • Конфигурации отладки по умолчанию для исходного файла launch.json, созданного VS Code.
  • Отладка фрагментов конфигурации, которые пользователь может добавить в файл launch.json.
  • Объявление переменных, которые можно использовать в конфигурациях отладки.

Дополнительную информацию можно найти в справочных материалах по материалам submits.breakpoints и serves.debuggers.

Помимо чисто декларативных функций, представленных выше, Debug Extension API обеспечивает следующие функции на основе кода:

  • Динамически генерируемые конфигурации отладки по умолчанию для исходного файла launch.json, созданного VS Code.
  • Определите адаптер отладки для динамического использования.
  • Проверьте или измените конфигурации отладки, прежде чем они будут переданы адаптеру отладки.
  • Свяжитесь с адаптером отладки.
  • Отправлять сообщения в консоль отладки.

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

Расширение фиктивной отладки

Поскольку создание отладочного адаптера с нуля немного сложно для этого руководства, мы начнем с простого DA, который мы создали в качестве образовательного «стартового набора отладочного адаптера». Он называется Mock Debug, потому что не взаимодействует с настоящим отладчиком, а имитирует его. Mock Debug имитирует отладчик и поддерживает пошаговое выполнение, продолжение, точки останова, исключения и доступ к переменным, но не подключен ни к какому настоящему отладчику.

Прежде чем углубляться в настройку разработки для mock-debug, давайте сначала установим готовую версию из VS Code Marketplace и поэкспериментируем с ней:

  • Переключитесь во вьюлет Extensions и введите "mock" для поиска расширения Mock Debug.
  • "Установить" и "Перезагрузить" расширение.

Чтобы попробовать фиктивную отладку:

  • Создайте новый пробный тест с пустой папкой и откройте его в VS Code.
  • Создайте файл readme.md и введите несколько строк произвольного текста.
  • Переключитесь в режим запуска и нажмите на значок шестеренки.
  • VS Code позволит вам выбрать «среду», чтобы создать конфигурацию запуска по умолчанию. Выберите «Имитация отладки».
  • Нажмите зеленую кнопку «Пуск», а затем «Ввод», чтобы подтвердить предложенный файл readme.md.

Начинается сеанс отладки, и вы можете «пошагово» пройти через файл readme, установить и нажать точки останова и столкнуться с исключениями (если слово «исключение» появляется в строке).

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

  • Переключитесь во вьюлет Extensions и щелкните значок шестеренки расширения Mock Debug.
  • Запустите действие "Удалить", а затем "Перезагрузите" окно.

Настройка разработки для имитации отладки

Теперь давайте получим исходный код для Mock Debug и начнем его разработку в VS Code:

Откройте папку проекта vscode-mock-debug в VS Code.

Что в упаковке?

  • package.json — это манифест для расширения mock-debug:
    • В нем перечислены возможности расширения mock-debug.
    • Сценарии компиляции и просмотра используются для переноса исходного кода TypeScript в выходную папку и наблюдения за последующими изменениями исходного кода.
    • Зависимости vscode-debugprotocol , vscode-debugadapter и vscode-debugadapter-testsupport — это модули NPM, которые упрощают разработку адаптеров отладки на основе узлов.

    Теперь создайте и запустите расширение Mock Debug, выбрав конфигурацию запуска расширения и нажав F5 . Первоначально это выполнит полную транспиляцию исходников TypeScript в выходную папку. После полной сборки запускается задача-наблюдатель, которая передает любые внесенные вами изменения.

    После переноса исходного кода появляется новое окно VS Code с надписью «[Узел разработки расширений]», в котором расширение Mock Debug теперь работает в режиме отладки. В этом окне откройте тестовый проект с файлом readme.md, запустите сеанс отладки с помощью клавиши «F5», а затем пройдитесь по нему:

    Поскольку вы запускаете расширение в режиме отладки, теперь вы можете устанавливать и нажимать точки останова в src/extension.ts, но, как я уже упоминал выше, в расширении выполняется не так много интересного кода. Интересный код выполняется в адаптере отладки, который является отдельным процессом.

    Для отладки самого адаптера отладки мы должны запустить его в режиме отладки. Этого проще всего добиться, запустив адаптер отладки в режиме сервера и настроив VS Code для подключения к нему. В проекте VS Code vscode-mock-debug выберите сервер конфигурации запуска в раскрывающемся меню и нажмите зеленую кнопку запуска.

    Поскольку у нас уже был активный сеанс отладки для расширения, пользовательский интерфейс отладчика VS Code теперь переходит в режим мультисеанса, на что указывают имена двух сеансов отладки Extension и Server, отображаемые в окне Представление СТЕК ВЫЗОВОВ:

    Теперь мы можем отлаживать расширение и DA одновременно. Более быстрый способ достичь этого — использовать конфигурацию запуска Extension + Server, которая запускает оба сеанса автоматически.

    Альтернативный, еще более простой подход к отладке расширения и DA можно найти ниже.

    Установите точку останова в начале метода launchRequest(. ) в файле src/mockDebug.ts и в качестве последнего шага настройте фиктивный отладчик для подключения к серверу DA, добавив атрибут debugServer для порта 4711 в конфигурацию запуска фиктивного теста:

    Если вы сейчас запустите эту конфигурацию отладки, VS Code не запустит фиктивный адаптер отладки как отдельный процесс, а напрямую подключится к локальному порту 4711 уже работающего сервера, и вы должны нажать точку останова в launchRequest .

    Благодаря этой настройке теперь вы можете легко редактировать, транспилировать и отлаживать Mock Debug.

    Но теперь начинается настоящая работа: вам придется заменить фиктивную реализацию адаптера отладки в src/mockDebug.ts и src/mockRuntime.ts некоторым кодом, который взаимодействует с «настоящим» отладчиком или средой выполнения. Это включает в себя понимание и реализацию протокола адаптера отладки. Подробнее об этом можно узнать здесь.

    Структура package.json расширения отладчика

    Помимо предоставления специфичной для отладчика реализации адаптера отладки, расширению отладчика требуется package.json, который вносит свой вклад в различные точки вклада, связанные с отладкой.

    Давайте подробнее рассмотрим package.json Mock Debug.

    Как и любое расширение VS Code, package.json объявляет имя основных свойств, издателя и версию расширения. Используйте поле категорий, чтобы упростить поиск расширения в магазине расширений VS Code.

    Теперь взгляните на раздел вкладов, который содержит вклады, относящиеся к расширениям отладки.

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

    Далее идет раздел отладчиков. Здесь один отладчик представлен под mock типа отладки. Пользователь может ссылаться на этот тип в конфигурациях запуска. Необязательную метку атрибута можно использовать, чтобы присвоить типу отладки красивое имя при его отображении в пользовательском интерфейсе.

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

    Поскольку VS Code работает на разных платформах, мы должны убедиться, что программа DA также поддерживает разные платформы. Для этого у нас есть следующие варианты:

    Если программа реализована независимым от платформы способом, например. как программу, работающую в среде выполнения, доступной на всех поддерживаемых платформах, вы можете указать эту среду выполнения с помощью атрибута среды выполнения. На сегодняшний день VS Code поддерживает среды выполнения node и mono. Наш макетный адаптер отладки, показанный выше, использует этот подход.

    Если для вашей реализации DA требуются разные исполняемые файлы на разных платформах, атрибут программы можно квалифицировать для конкретных платформ следующим образом:

    Возможна комбинация обоих подходов. Следующий пример взят из Mono DA, которое реализовано как моноприложение, которому требуется среда выполнения в macOS и Linux, но не в Windows:

    configurationAttributes объявляет схему для атрибутов launch.json, доступных для этого отладчика. Эта схема используется для проверки файла launch.json и поддержки IntelliSense и справки при наведении курсора при редактировании конфигурации запуска.

    InitialConfigurations определяет начальное содержимое файла launch.json по умолчанию для этого отладчика. Эта информация используется, когда в проекте нет файла launch.json, а пользователь запускает сеанс отладки или щелкает значок шестеренки в представлении «Выполнение». В этом случае VS Code позволяет пользователю выбрать среду отладки, а затем создает соответствующий файл launch.json:

    Вместо статического определения начального содержимого launch.json в package.json можно динамически вычислить начальные конфигурации, внедрив DebugConfigurationProvider (подробности см. в разделе Использование DebugConfigurationProvider ниже).

    configurationSnippets определяют фрагменты конфигурации запуска, которые отображаются в IntelliSense при редактировании файла launch.json . По соглашению предваряйте атрибут label фрагмента именем среды отладки, чтобы его можно было четко идентифицировать при представлении в списке множества предложений фрагментов.

    Вклад переменных связывает «переменные» с «командами». Эти переменные можно использовать в конфигурации запуска с использованием синтаксиса $, а переменные заменяются значением, возвращаемым связанной командой при запуске сеанса отладки.

    Реализация команды находится в расширении и может варьироваться от простого выражения без пользовательского интерфейса до сложной функциональности, основанной на функциях пользовательского интерфейса, доступных в API расширения.Mock Debug связывает переменную AskForProgramName с командой extension.mock-debug.getProgramName . Реализация этой команды в src/extension.ts использует showInputBox, чтобы позволить пользователю ввести имя программы:

    Теперь эту переменную можно использовать в любом строковом значении конфигурации запуска как $ .

    Использование DebugConfigurationProvider

    Если статического характера вкладов отладки в package.json недостаточно, DebugConfigurationProvider можно использовать для динамического управления следующими аспектами расширения отладки:

    • Первоначальные конфигурации отладки для вновь созданного файла launch.json можно создавать динамически, например. на основе некоторой контекстной информации, доступной в рабочей области.
    • Конфигурация запуска может быть разрешена (или изменена) до того, как она будет использована для запуска нового сеанса отладки. Это позволяет заполнять значения по умолчанию на основе информации, доступной в рабочей области. Существует два метода resolve: метод resolveDebugConfiguration вызывается до замены переменных в конфигурации запуска, метод resolveDebugConfigurationWithSubstitutedVariables вызывается после замены всех переменных. Первый должен использоваться, если логика проверки вставляет дополнительные переменные в конфигурацию отладки. Последний следует использовать, если логике проверки требуется доступ к окончательным значениям всех атрибутов конфигурации отладки.

    MockConfigurationProvider в src/extension.ts реализует resolveDebugConfiguration для обнаружения случая, когда сеанс отладки запускается, когда файл launch.json не существует, но в активном редакторе открыт файл Markdown. Это типичный сценарий, когда у пользователя есть файл, открытый в редакторе, и он просто хочет отладить его, не создавая файл launch.json.

    Поставщик конфигурации отладки регистрируется для определенного типа отладки через vscode.debug.registerDebugConfigurationProvider , обычно в функции активации расширения. Чтобы убедиться, что DebugConfigurationProvider зарегистрирован достаточно рано, расширение необходимо активировать сразу после использования функции отладки. Этого легко добиться, настроив активацию расширения для события onDebug в package.json :

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

    Для дорогостоящих расширений отладки лучше использовать более детализированные события активации:

    • onDebugInitialConfigurations запускается непосредственно перед вызовом метода ProvideDebugConfigurations поставщика DebugConfigurationProvider.
    • onDebugResolve:type запускается непосредственно перед вызовом методов resolveDebugConfiguration или resolveDebugConfigurationWithSubstitutedVariables поставщика DebugConfigurationProvider для указанного типа.

    Практическое правило: если активация расширений отладки обходится дешево, используйте onDebug . Если это дорого, используйте onDebugInitialConfigurations и/или onDebugResolve в зависимости от того, реализует ли DebugConfigurationProvider соответствующие методы providerDebugConfigurations и/или resolveDebugConfiguration .

    Публикация расширения отладчика

    После создания расширения отладчика его можно опубликовать в Marketplace:

    • Обновите атрибуты в package.json, чтобы они отражали название и назначение вашего расширения отладчика.
    • Загрузить в Marketplace, как описано в расширении для публикации.

    Альтернативный подход к разработке расширения отладчика

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

    Этот подход на самом деле легко выполним, если ваш адаптер отладки реализован на TypeScript/JavaScript. Основная идея состоит в том, чтобы запустить адаптер отладки непосредственно внутри расширения и заставить VS Code подключаться к нему вместо запуска нового внешнего адаптера отладки для каждого сеанса.

    Для этого VS Code предоставляет API-интерфейс расширения для управления созданием и запуском адаптера отладки. DebugAdapterDescriptorFactory имеет метод createDebugAdapterDescriptor, который вызывается VS Code, когда начинается сеанс отладки и требуется адаптер отладки. Этот метод должен возвращать объект дескриптора ( DebugAdapterDescriptor ), который описывает, как запускается адаптер отладки.

    Сегодня VS Code поддерживает три разных способа запуска адаптера отладки и, следовательно, предлагает три разных типа дескрипторов:

    Имитация отладки показывает примеры для трех типов DebugAdapterDescriptorFactories и то, как они регистрируются для фиктивного типа отладки. Используемый режим запуска можно выбрать, задав для глобальной переменной runMode одно из возможных значений external , server , или inline .

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

    Часто появляется всплывающее окно отладчика Just-In-Time отладчика Visual Studio? вот как это отключить:

    • Во всплывающем окне Just-In-Time Debugger выберите «Новый экземпляр Microsoft Visual Studio 2010» и нажмите кнопку «Да» для параметра «Вы хотите выполнять отладку с помощью выбранного отладчика?».
    • При этом открывается Visual Studio. Закройте окно сообщения об ошибке. Выберите "Инструменты" > "Параметры" > "Отладка" > "Точно вовремя".
    • В диалоговом окне Just-In-Time снимите флажок со всех параметров (управляемый, собственный и сценарий) и нажмите «ОК», чтобы сохранить изменения.


    Вот и все!

    Похожие записи

    Салаудин Раджек

    Салаудин Рэджек — архитектор SharePoint с двадцатилетним опытом работы с SharePoint. Ему нравится делиться своими знаниями и опытом с сообществом SharePoint с помощью своих реальных статей!

    Оставить ответ Отменить ответ

    Обо мне

    Салодин Рэджек – архитектор SharePoint. В первую очередь по инфраструктуре, эксплуатации, администрированию и архитектуре!

    Хотите внести свой вклад?
    Являетесь ли вы экспертом по SharePoint? Что ж, вы можете начать вносить свой вклад в этот сайт! Узнайте прямо сейчас: как внести свой вклад и что вы получите взамен?

    Архив
    Категории

    SharePoint Online: переключение навигации на горизонтальную или вертикальную

    Как подключиться к Exchange Online с помощью PowerShell?

    Как скопировать разрешения из одной папки в другую в SharePoint Online с помощью PowerShell?

    Как скопировать разрешения пользователей в SharePoint Online с помощью PowerShell?

    SharePoint Online: как изменить автора на современной странице?

    Исправлено отсутствие функции «Просмотр в проводнике» в выпуске SharePoint Online

    SharePoint Online: отключить создание рабочего процесса SharePoint Designer

    Как создать страницу глоссария от А до Я в SharePoint Online?

    Изменить текст «Новый элемент» в современном списке SharePoint Online

    Срок действия доступа внешних пользователей в SharePoint Online и OneDrive для бизнеса

    Отказ от ответственности

    Это мой личный блог. Статьи, написанные в этом блоге, основаны на моем личном опыте и предназначены для помощи другим.

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

    Читайте также: