Какое имя у файла приложения сервера отладки
Не уверен что данной информации нет, но все что находил содержало либо частичную настройку либо недостоверные / сложно реализуемые способы.
Суть проблемы: есть множество мобильных приложений и мобильных клиентов и необходимо их отлаживать как в процессе разработки так и в процессе использования, т.е. когда сами устройства где-то по стране гуляют.
Решение будет описано в контексте мобильного клиента, т.к. работа шла на нем.
Еще до отладки было необходимо реализовать подключение мобильного клиента к самой БД. Суть сборки описана тут, но есть нюанс который там не освещен нигде, а именно то, что адрес во внутренней сети и во внешней отличается. Да, это банальность, но я на нее напоролся))
Возможно вышеописанные действия не самые корректные, но по крайне мере это работает, а каких-то адекватных решений и разборов проблем по мобильному клиенту пока еще маловато.
П.С. Вообще в компании я запросил отдельный сервер со своим IIS для всяких мобильных приложений, поэтому с манипуляциями на этом сервере проблем не возникло, а строка подключения прописывается при сборке мобильного клиента и пользователям о ней знать не обязательно.
Если подключение мобильного клиента успешно выполнено, то у вас уже должна быть доступна отладка, но только серверной части. Естественно сервер должен быть запущен в режиме отладки, поэтому данный момент опускаем, да и материалов по этому поводу навалом, однако отладка клиента будет недоступна.
Для реализации отладки клиента мобильного приложения необходимо:
Последним шагом будет являться установка адреса сервера отладки на мобильном устройстве, которое необходимо отладить и установка признака "отладка разрешена", тоже на мобильном устройстве.
Сам путь можно посмотреть в конфигураторе, в окне настроек параметров отладки.
Кроме этого отмечу, что эта статья входит в небольшую серию статей об отладке в 1С:
Предмет отладки
Типы предметов отладки:
Подключение предметов отладки зависит от выбранного протокола отладки и поэтому будет рассмотрено ниже.
Выбор протокола отладки
Выбор протокола отладки
- Использовать локальный сервер отладки — вариант в основном для файловых информационных баз, в дополнительных полях можно указать адрес сетевой карты (если их несколько), а также один или несколько диапазонов портов которые будут использоваться для отладки, например: 1560:1591, 7700-8000;
- Использовать удаленный сервер отладки — конфигуратор попытается подключиться к удаленному серверу отладки по указанному адресу и порту;
- Использовать сервер отладки кластера — используется сервер отладки кластера серверов, кластер серверов должен быть запущен в отладочном режиме.
Протокол отладки TCP/IP
При отладке по протоколу TCP/IP отладчик ищет доступные предметы отладки на текущем или указанном компьютере. Для корректной работы отладчика (если конечно речь идет не о файловой базе на одного пользователя) очень рекомендуется нормально настроить сеть — в частности DNS-сервер и доступность отладочных портов (по-умолчанию 1560:1591).
Подключение предметов отладки
В список доступных предметов отладки попадают только те из них, которые отвечают следующим требованиям:
- отладчик и предмет отладки имеют одинаковый идентификатор информационной базы;
- в приложении включена возможность отладки (для сервера — см. первую статью серии, для клиентского приложения — соответствующий параметр командной строки либо свойство в диалоге настройки клиентского приложения либо соответствующие указания в конфигурационном файле);
- отсутствуют в списке подключенных предметов отладки.
Настройки отладчика
Некоторые типы предметов отладки остаются доступными для подключения очень непродолжительное время, в этом случае нужно воспользоваться настройками автоматического подключения предметов отладки:
Настройки автоматического подключения
Сервер отладки
Сервер отладки обычно запускается конфигуратором (в файловом варианте) или кластером серверов (если кластер запущен в режиме отладки).
Кроме этого сервер отладки может быть запущен вручную — для реализации нетривиальных сценариев отладки.
Сервер отладки (dbgs) находится в каталоге bin, параметр --help покажет информацию об имеющихся параметрах запуска (там все довольно понятно), пример запуска:
C:\Program Files\1cv8\8.3.13.1513\bin\dbgs -a 192.168.0.170 -p 4000
Сервер отладки готов к работе
Подключение предметов отладки
Подключение предметов отладки
Из списка доступных предметов отладки исключаются уже подключенные и не соответствующие отбору предметы отладки. Отбор можно установить в правой верхней части окна:
Отбор предметов отладки
В окне настроек отладчика можно узнать адрес сервера отладки и имя информационной базы:
Для настройки автоматического подключения предметов отладки существует специальный диалог:
В левой части диалога можно указать типы предметов отладки, которые подлежат автоматическому подключению, а в правой — дополнительные отборы предметов отладки.
На этом все, надеюсь, что эта статья была Вам полезна. Также напомню про другие статьи серии об отладке в 1С, ссылки на них можно найти в начале этой статьи.
Если Вы нашли ошибку или неточность, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
(оценок: 1, средняя оценка: 5,00 из 5)Тема включения режима отладки на сервере 1С весьма актуальна, по ней в сети Интернет написано много интересных статей, но большинство из них не полностью решают проблему. Если перед тобой стоит задача включения режима отладки на сервере 1С, то эта статья несомненно поможет в этом!
Тема включения режима отладки на сервере 1С весьма актуальна, по ней в сети Интернет написано много интересных статей, но большинство из них не полностью решают проблему. Если перед тобой стоит задача включения режима отладки на сервере 1С, то эта статья несомненно поможет в этом!
Из официальных источников мы имеем следующую информацию:
Думаю, мало кому из нас этого будет достаточно, чтобы без дополнительных источников информации и знаний запустить 1С в режиме отладки.
Допустим, ты отвечаешь за ИТ инфраструктуру и к тебе подходит программист 1С, чтобы попросить запустить 1С в режиме отладки.
Поздравляю! Программист 1С не является доменным администратором и не смог произвести настройку самостоятельно. Вопросы безопасности и чувства самосохранения не на последнем месте.
1С в серверном варианте требует комплексного подхода, который достигается наличием достаточных компетенций у специалистов из разных направлений – программист 1С, системный администратор, администратор баз данных.
И когда речь уже заходит об отладке приложения, универсальные солдаты «тыжсисадмин» и «тыжпрограммист» уже не актуальны. На данном уровне навыки для системного администратора и программиста 1С сильно разнятся и совмещать их, оставаясь профессионалом с большой буквы «П», уже невозможно.
Действующие акции
Как запустить сервер 1С в режиме отладки правильно?
По умолчанию служба агента сервера 1С запускается без режима отладки, так как он уменьшает скорость работы в программе.
Есть несколько вариантов, но рассмотрим самый ходовой – изменение значения параметра реестра Windows.
Открываем реестр на сервере, где установлен сервер 1С.
Переходи по следующему пути:
Имя раздела может отличаться в зависимости от версии сервера 1С – 8.2 / 8.1 или его архитектуры – 32 / 64 битный.
Здесь нас интересует параметр ImagePath, а точнее его значение, которое и надо дополнить ключом «debug».
ПРИМЕЧАНИЕ! В разных статьях указаны различные варианты запуска режима отладки и это может ввести в заблуждение. Ключ «debug» можно добавлять в любое место после "C:\Program Files\1cv8\8.3.13.1644\bin\ragent.exe" и использовать как знак «-», так и «/».
Например, будут одинаково работать:
Первый вариант смотрится предпочтительней.
На выходе должно получиться следующее:
Перезапускаем службу «Агент сервера 1С:Предприятия 8.3 (x86-64)».
Поздравляю – режим отладки включен!
Осталось проверить его работу.
Самый простой способ проверки работы режима отладки 1С на сервере
Если платформа 1С для проведения отладки будет запускаться не на сервере 1С, на стороне клиента должны быть открыты TCP и UDP порты для диапазона 1560-1591.
На стороне сервера должны быть открыты TCP порты 1540, 1541, 1560-1591.
ПРИМЕЧАНИЕ! Эти порты устанавливаются по умолчанию, если вы их меняли, то в фаерволе надо будет открыть новые.
Проверяем работу отладчика:
- Запускаем конфигуратор.
- Заходим в меню «Отладка» — «Начать отладку» или нажимаем клавишу «F5». Запустится платформа 1С в режиме предприятия.
- Не закрывая 1С предприятие, переходим в меню «Отладка» — «Подключение…».
Если столбец «Тип» заполнен значением «Сервер», то всё работает. Идём писать письмо программисту 1С.
ПРИМЕЧАНИЕ! Если сервер и клиент – не один сервер, ставим галочку «Искать предметы отладки на удаленном компьютере»: и указываем сервер 1С.
В блоке «Доступные предметы отладки:» столбец «Тип» должен быть заполнен значением «Сервер». Если у вас так, то всё работает.
Арендуя сервер для 1С в компании МАРС Телеком, вы всегда сможете получить помощь наших технических специалистов по этому и другим вопросам.
Обычным тестированием кода в 1С уже никого не удивишь. Для платформы появились удобные фреймворки тестирования с низким порогом вхождения. Всё больше разработчиков начинает их использовать в своей работе. Некоторые из них настраивают сборочные конвейеры, выгружают результаты в SonarQube . На эту тему написана не одна статья, проведен не один семинар, снято множество видео на youtube. Но практически во всех инструкциях обходится стороной вопрос получения показателей покрытия кода тестами.
Покрытие кода — мера, используемая при тестировании программного обеспечения. Она показывает процент исходного кода программы, который был выполнен в процессе тестирования. © Википедия
Логично предположить что чем выше покрытие кода, тем меньше ошибок должен содержать исходный код.
Любимый 1С-программистами SonarQube умеет показывать покрытие по двум показателям: покрытие строк и покрытие ветвей. Покрытие строк показывает какие строки кода были выполнены при тестировании, а какие нет. Покрытие ветвей вместо строк кода оперирует ветками условных операторов. Например код “Результат = ?(А>0, Б/А, 0);” содержит одну строку, но две ветки, которые мы должны протестировать. К сожалению платформа предоставляет только информацию по выполненным строкам кода, поэтому покрытие ветвей рассматриваться не будет.
Как осуществлялся анализ покрытия раньше?
Пару раз сохранив по сотне-другой запросов я принялся искать новый инструмент.
Для этого поднимается прокси-сервер, который сохраняет проходящие через него данные в лог файл, а затем логи конвертируются в один из стандартных форматов. Большинство действий выполняется этими утилитами автоматически, но они также имеют множество проблем. Это и сложность работы с клиент-серверными базами, и невозможность декодирования замеров производительности из бинарного формата.
Можно ли сделать проще?
- регистрироваться в качестве клиента сервера отладки dbgs.exe;
- подключать все доступные объекты отладки;
- включать замеры производительности;
- конвертировать результаты замеров в формат genericCoverage для SonarQube ;
- работать как с файловыми, так и с клиент-серверными базами.
Данный продукт уже некоторое время используется при тестировании проектов 42Облака.
При необходимости, в командной строке регистрации сервера «1С:Предприятия» также можно указать значения параметров /debugServerAddr , /debugServerPort и /debugServerPwd .
При запуске клиента файловой базы из командной строки, сервер отладки не запускается автоматически. Поэтому dbgs.exe нужно запускать вручную. Его исполняемый файл находится в папке с клиентом 1С предприятия соответствующей версии платформы. Сервер отладки имеет несколько полезных параметров командной строки:
Параметры --addr и --port должны совпадать с адресом отладчика, передаваемому в клиент тестирования. Если вы не знаете какой порт будет свободен на момент запуска, можно применить параметры --portRange и --notify . В первый параметр передается диапазон возможных портов, например 1550:1999 . Сервер отладки сам выберет свободный порт и запишет свой адрес в файл, указанный в параметре --notify . Параметр --ownerPID нужен для того чтобы не контролировать жизненный цикл сервера отладки. После завершения процесса, PID которого передан в этом параметре, сервер отладки завершится самостоятельно. Если вы используете менеджер/клиент тестирования, то в этом случае вам необходимо включить отладку только в клиенте тестирования. Обратите внимание что регламентные задания также должны выполняться в клиенте тестирования. Для этого менеджер тестирования запускайте с параметрами “/AllowExecuteScheduledJobs -Off” .
Запуск автоматического анализа покрытия
Для проверки работоспособности программы, можно запустить её без аргументов командной строки. Если система настроена корректно, будет выведена справка. Далее можно приступать к тестированию.
- Выгружаем конфигурацию/расширение/внешнюю обработку в файлы (поддерживается как формат EDT, так и конфигуратора);
- Запускаем сервер отладки (только для файловой базы);
- Запускаем сбор данных покрытия командой Coverage41C start с параметрами командной строки:
Параметры -P и -s нужны для того чтобы передать в SonarQube корректный относительный путь к исходникам. Например ваши исходники находятся в папке “D:\Path\To\Sources\Project1\src\” и в SonarQube выгружается директория “D:\Path\To\Sources\Project1\” , тогда параметр -P должен быть равен “D:\Path\To\Sources\Project1\” , а -s иметь значение “src” . А если в SonarQube выгружается директория “D:\Path\To\Sources\Project1\src\” , то параметр -P должен содержать полный путь к исходникам “D:\Path\To\Sources\Project1\src\” , а параметр -s можно опустить. Если вы анализируете внешнюю обработку, то указывается путь не к директории с исходниками, а путь к xml (или mdo для EDT ) файлу с описанием внешней обработки.
После запуска программа Coverage41C прочитает исходники из указанной директории, подключится к серверу отладки и запустит замеры производительности для всех доступных объектов отладки. На инициализацию потребуется некоторое время, в зависимости от размера исходных кодов. Убедится в завершении инициализации программы можно выполнив в соседнем окне команду Coverage41C check с параметрами -i (имя информационной базы) и -u (или -u:file - адрес сервера отладки). Команда check завершится с кодом 0 после инициализации основной команды. После этого можно начинать тестирование.
Адрес отладчика нужно указывать нужно указывать такой же, как и для остальных инструментов.
После выполнения всех тестов нужно остановить анализ покрытия командой Coverage41C stop с параметрами -i (имя информационной базы) и -u (или -u:file - адрес сервера отладки). Команда stop также дожидается выполнения записи данных покрытия в файл и возвращает код 0 при успешном выполнении.
Далее файл genericCoverage.xml можно передать в SonarQube .
Запуск анализа покрытия с конвертацией
Если на сервере тестирования отсутствуют актуальные исходники тестируемого кода, существует возможность сбора данных покрытия во внутренний формат с последующей конвертацией в стандартный genericCoverage.xml . Для этого при запуске команды Coverage41C start нужно не указывать параметры -P и -s . После завершения анализа, мы получим файл во внутреннем формате, где вместо путей к исходникам будут указаны uuid метаданных. Данный файл можно преобразовать в genericCoverage.xml командой Coverage41C convert . У данной команды параметры аналогичны команде start , за исключением того что параметры подключения к серверу отладки тут отсутствуют и добавлен параметр
Работа без установленного EDT
Для работы программы требуются библиотеки EDT com._1c.g5.v8.dt.debug.core_*.jar и com._1c.g5.v8.dt.debug.model_*.jar. Если установить на сервер тестирования EDT полностью затруднительно, то можно скопировать эти библиотеки из папки с установленным EDT и указать путь к ним в переменной окружения EDT_LOCATION .
Передача данных покрытия в SonarQube
-Dsonar.sources=src -D"sonar.inclusions=**/*.bsl, **/*.os"
В результате в SonarQube мы получим процент покрытия на странице проекта:
Кроме этого будет доступна детализация на странице исходников:
Зелёными отметками выделен код, исполнявшийся при тестировании. Красными - не исполнявшийся код.
Замеры покрытия по сценариям
Утилита поддерживает возможность анализа покрытия в разрезе сценариев. Для этого предназначены команды dump и clean . Команда dump записывает файл покрытия, команда clean очищает информацию о покрытии. Обе команды принимают параметры -i и -u . Таким образом если перед выполнением сценария запустить команду clean , а после выполнения - команду dump , то в файл запишется информация о покрытии исходного кода текущим тестовым сценарием.
Запуск анализа из Vanessa-ADD
Если вам не нравится работать с командной строкой, есть возможность подключить библиотеку шагов для BDD тестирования и управлять анализом покрытия из Gerkin - кода. Библиотека шагов сама скачивает последнюю версию Coverage41C , определяет имя текущей информационной базы и адрес сервера отладки. Библиотека добавляет следующие шаги:
Для корректной работы нужно в первом сценарии или в контексте установить параметры до запуска замеров (имя выходного файла, путь к проекту и исходникам, при необходимости - имя расширения, путь к внешней обработке, пароль, имя ИБ и адрес сервера отладки). Если Coverage41C не установлен в системе глобально, вызываем его установку в каталог проекта командой “я устанавливаю Coverage41C” . Далее запускаем анализ командой “я запускаю анализ покрытия” . Для записи результатов в файл нужно после выполнения последнего сценария вызвать команду “я останавливаю анализ покрытия” либо просто завершить процесс менеджера тестирования. Для файловых баз из кода можно запускать сервер отладки командой “я запускаю сервер отладки (в диапазоне портов)” .
Сохранение результатов покрытия в файл происходит при выполнении команды “Я останавливаю анализ покрытия”, либо “Я сохраняю данные покрытия”, либо после завершения процесса менеджера тестирования.
Кроме этого отмечу, что эта статья входит в небольшую серию статей об отладке в 1С:
Предмет отладки
Начнем с обсуждения такого понятия, как «предмет отладки». Предмет отладки — это контекст встроенного языка, который характеризуется такими параметрами как:
Типы предметов отладки:
Подключение предметов отладки зависит от выбранного протокола отладки и поэтому будет рассмотрено ниже.
Выбор протокола отладки
Выбрать протокол отладки можно в конфигураторе: Главное меню->Сервис->Параметры->вкладка «Отладка»:
Выбор протокола отладки
Группа «Сервер отладки» позволяет указать, каким сервером отладки нужно воспользоваться:
- Использовать локальный сервер отладки — вариант в основном для файловых информационных баз, в дополнительных полях можно указать адрес сетевой карты (если их несколько), а также один или несколько диапазонов портов которые будут использоваться для отладки, например: 1560:1591, 7700-8000;
- Использовать удаленный сервер отладки — конфигуратор попытается подключиться к удаленному серверу отладки по указанному адресу и порту;
- Использовать сервер отладки кластера — используется сервер отладки кластера серверов, кластер серверов должен быть запущен в отладочном режиме.
Группа «Имя информационной базы» позволяет указать имя информационной базы, под которым отладчик зарегистрируется на сервере отладки. Если доступ к серверу отладки защищен паролем, то этот пароль можно указать в группе «Доступ».
Протокол отладки TCP/IP
При отладке по протоколу TCP/IP отладчик ищет доступные предметы отладки на текущем или указанном компьютере. Для корректной работы отладчика (если конечно речь идет не о файловой базе на одного пользователя) очень рекомендуется нормально настроить сеть — в частности DNS-сервер и доступность отладочных портов (по-умолчанию 1560:1591).
Подключение предметов отладки
Для выполнения отладки модуля нужно подключить предмет отладки. Подключенные и доступные для подключения предметы отладки, а также настройки отладчика и автоматического подключения можно увидеть в диалоге «Предметы отладки» (меню «Отладка»->»Подключение»):
Диалог «Предметы отладки»
В список доступных предметов отладки попадают только те из них, которые отвечают следующим требованиям:
- отладчик и предмет отладки имеют одинаковый идентификатор информационной базы;
- в приложении включена возможность отладки (для сервера — см. первую статью серии, для клиентского приложения — соответствующий параметр командной строки либо свойство в диалоге настройки клиентского приложения либо соответствующие указания в конфигурационном файле);
- отсутствуют в списке подключенных предметов отладки.
"Параметры")" w /> Настройки клиентского приложения («Сервис»->»Параметры»)
Кнопка «Настройка…» открывается окно с настройками:
Настройки отладчика
В этом окне можно изменить отладочные порты которые будет сканировать отладчик в поисках подходящих предметов отладки. Кроме этого можно узнать адрес отладчика (строка «Отладчик:»), этот адрес пригодится при различных видах отладки в файловых базах (подробнее об этом в следующей статье).
Некоторые типы предметов отладки остаются доступными для подключения очень непродолжительное время, в этом случае нужно воспользоваться настройками автоматического подключения предметов отладки:
Настройки автоматического подключения
Сервер отладки
Сервер отладки обычно запускается конфигуратором (в файловом варианте) или кластером серверов (если кластер запущен в режиме отладки).
Кроме этого сервер отладки может быть запущен вручную — для реализации нетривиальных сценариев отладки.
C:Program Files1cv88.3.13.1513indbgs -a 192.168.0.170 -p 4000
Сервер отладки готов к работе
Подключение предметов отладки
Подключение предметов отладки
Из списка доступных предметов отладки исключаются уже подключенные и не соответствующие отбору предметы отладки. Отбор можно установить в правой верхней части окна:
Отбор предметов отладки
В окне настроек отладчика можно узнать адрес сервера отладки и имя информационной базы:
Для настройки автоматического подключения предметов отладки существует специальный диалог:
В левой части диалога можно указать типы предметов отладки, которые подлежат автоматическому подключению, а в правой — дополнительные отборы предметов отладки.
На этом все, надеюсь, что эта статья была Вам полезна. Также напомню про другие статьи серии об отладке в 1С, ссылки на них можно найти в начале этой статьи.
Если Вы нашли ошибку или неточность, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Реализовано в версии 8.3.7.1759.
Мы значительно переработали механизм отладки. Для этого было несколько причин. Во-первых, мы хотели предоставить вам возможность отлаживать все имеющиеся на сегодняшний момент приложения. Во-вторых, прежняя архитектура отладчика требовала изменений для того, чтобы соответствовать текущим тенденциям, и иметь возможность будущего развития. В-третьих, был необходим универсальный интерфейс отладки, с которым мог бы работать не только конфигуратор 1С:Предприятия, но и Development Tools.
Основные преимущества
Чтобы вы могли представить себе объём выполненных нами изменений, коротко перечислим основные преимущества нового механизма.
Прежний механизм отладки был основан на том, что отладчик, реализованный в конфигураторе 1С:Предприятия, напрямую взаимодействовал с предметами отладки (клиентскими и серверными приложениями). Это взаимодействие осуществлялось по протоколу TCP/IP.
Однако с выходом приложений 1С:Предприятия в Интернет, а особенно с появлением мобильных приложений, такой подход стал источником ограничений и неудобств. Далеко не всегда протокол TCP/IP позволяет отладчику «достучаться» до предметов отладки. Ведь они могут находиться вне локальной сети, в которой работает отладчик.
Современная архитектура отладки
Особенностью прежнего механизма отладки была необходимость подключения к информационной базе с помощью конфигуратора. В результате разработчик, выполняющий отладку, имел полный доступ ко всем административным функциям.
Новый механизм отладки перестал нуждаться в соединении с отлаживаемой информационной базой. Главное, что требуется теперь отладчику, это такая же конфигурация, которая работает у клиентов. Для её получения нет необходимости подключаться к отлаживаемой информационной базе. Вы можете загрузить её, например, из файла.
Отладка мобильных приложений
Изменение переменных, свойств объектов и асинхронные вычисления выражений
Теперь в процессе отладки вы можете изменять значения любых переменных, которые доступны для записи. Для быстрого просмотра и изменения локальных переменных мы реализовали отдельное окно. А само вычисление выражений, отображаемых отладчиком, теперь выполняется в асинхронном режиме.
Отладка в Development Tools
При создании нового механизма отладки мы реализовали новый, универсальный программный интерфейс взаимодействия с ним. Этот интерфейс использует конфигуратор 1С:Предприятия, и этот же интерфейс использует теперь и новая среда разработки 1C:Enterprise Development Tools. Таким образом, все возможности отладки доступны теперь и при работе в Development Tools.
Архитектура процесса отладки
Новая архитектура отладки выглядит следующим образом:
Таким образом, взаимодействие получается одностороннее. Информация всё время передаётся с сервера отладки в отладчик, и в предметы отладки.
Идентификация информационных баз
В прежнем механизме для идентификации информационных баз использовалась строка соединения. Такое решение в некоторых случаях вызывало трудности с сопоставлением предметов отладки и конфигуратора. Потому что, во-первых, оно было регистрозависимым, а во-вторых, при отладке некоторых контекстов платформа формировала строку соединения автоматически. И она не всегда совпадала с той, которую вы указывали при подключении информационной базы в конфигураторе. Поиск и исправление таких ситуаций усложняли процесс отладки.
В новом механизме мы избавились от строки соединения. Теперь мы используем идентификатор информационной базы. В файловой информационной базе такой идентификатор генерируется при первом подключении клиентского соединения. В серверной информационной базе в качестве такого идентификатора используется идентификатор регистрации информационной базы в кластере.
Приятным дополнительным моментом здесь является то, что мы пока сохранили в платформе старый механизм отладки (в дальнейшем он может быть исключён). И вы можете пользоваться им при желании, или при необходимости. Так вот старый механизм мы доработали, и теперь он тоже использует идентификатор информационной базы, а не строку соединения.
Типичные сценарии отладки
С точки зрения прикладного разработчика типичные сценарии отладки не изменились. Единственным значительным отличием является то, что новый механизм отладки нужно включить. Потому что по-умолчанию он выключен.
Несмотря на это имеет смысл познакомиться с тем, что происходит теперь при запуске отладки. Потому что это может быть полезно вам в каких-то нестандартных сценариях работы.
Файловый вариант
При этом конфигуратор автоматически предложит вам использовать локальный сервер отладки. С этим нужно согласиться и перезапустить конфигуратор.
Установленный вами способ отладки сохраняется между сеансами конфигуратора, но хранится он в разрезе информационных баз. Поэтому для другой информационной базы вам снова нужно будет его включить.
Теперь при старте конфигуратора, или при его перезапуске, платформа автоматически будет запускать ещё и сервер отладки. Это отдельное приложение dbgs.exe. Вы можете увидеть его в диспетчере задач.
В параметре ownerPID у него указан идентификатор того приложения, которому принадлежит этот сервер отладки. В данном случае это конфигуратор 1С:Предприятия.
Теперь, если из конфигуратора вы запустите отладочный сеанс 1С:Предприятия, он автоматически подключится к серверу отладки, и в конфигураторе вы увидите подключенные предметы отладки.
Если сеанс 1С:Предприятия был запущен без отладки, то, как и раньше, вы можете подключить его к отладчику. Только теперь нужно указывать адрес сервера отладки:
Этот адрес вы можете узнать из настроек предметов отладки:
Поэтому если у вас открыты сразу несколько конфигураторов, то для подключения клиентского приложения к отладчику вам нужно выбрать из них правильный.
Клиент-серверный вариант
При таком запуске сервера будет запущен и сервер отладки.
В параметре ownerPID у него будет указан идентификатор менеджера кластера 1С:Предприятия.
При этом конфигуратор автоматически предложит вам использовать уже сервер отладки кластера, а не локальный сервер. С этим нужно согласиться и перезапустить конфигуратор.
Подключение предметов отладки
При запуске отладочных сеансов из конфигуратора, приложения выполняют автоматическое подключение предметов отладки (как клиентского, так и серверного) к серверу отладки.
При этом, как и раньше, у вас есть возможность настроить в конфигураторе автоматическое подключение предметов отладки независимо от того, каким образом они были запущены. Теперь эти возможности стали гораздо богаче.
Во-первых, теперь платформа предлагает вам для выбора все возможные предметы отладки.
А во-вторых, появился ещё один, более тонкий способ настройки. Это использование заранее созданных отборов.
Такие отборы вы можете использовать как при подключении предметов отладки, так и для просмотра доступных предметов отладки.
В отборе, кроме самих предметов отладки, вы можете указать конкретных пользователей, чьи сеансы вас интересуют, а также, если используется разделение данных, указать область информационной базы, которая будет отлаживаться.
Изменение переменных, свойств объектов и асинхронные вычисления выражений
Новый механизм отладки позволяет вам изменять значения переменных в процессе отладки. В прежнем механизме такая возможность отсутствовала.
Для удобного просмотра и изменения локальных переменных, что представляется наиболее частой задачей, мы реализовали окно «Локальные переменные».
Внешне оно очень похоже на привычное вам «Табло». Но, во-первых, это окно уже автоматически заполнено всеми локальными переменными, а во-вторых, значения переменных вы можете теперь менять.
Значения примитивных типов вы можете изменить прямо в ячейке «Значение»:
А для изменения других значений вы можете воспользоваться окном ввода выражений:
Приятным бонусом является то, что в этом окне полностью функционирует контекстная подсказка.
Точно таким же образом вы можете изменять и значения любых (не только локальных) переменных, свойств, доступных для записи. В окне вычисления выражений (которое вызывается командой Shift+F9) вы можете менять значения переменных как в ячейке «Значение», так и с помощью отдельного диалога.
Кстати, само вычисление выражений теперь выполняется асинхронно. Это означает, что конфигуратор заказывает вычисление предмета отладки. И некоторое время это вычисление ожидается на сервере. Если вычисление выполнено, то результаты сразу поступают в конфигуратор. Если вычисление выполняется продолжительное время, то результаты этих вычислений асинхронно приходят в конфигуратор позже. Такой подход позволяет вам не ожидать длительных вычислений в конфигураторе, и продолжить свою работу.
Автор: Admin Сентябрь 2, 2019 0 комментария
Ни один разработчик 1с не может выполнять серьезные задачи или находить ошибки в коде без отладки. Так что же делать если не работает механизм отладки? Все очень просто!
Для начала смотрим какой режим отладки у нас включен в параметрах конфигурации “Сервис/Параметры/Закладка ‘Отладка’ “:
В большинстве случаев достаточно отладки по сетевому протоколу TCP/IP – ‘Отладка по протоколу TCP/IP’. Двумя словами: конфигуратор напрямую взаимодействует с предметами отладки (клиентские приложения, фоновые задания и т.д.).
Что бы подключиться к отлаживаемому приложению, не обязательно нужно занимать конфигуратор – достаточно иметь копию конфигурации отслеживаемого приложения. Более подробно с новым механизмом отладки можно ознакомиться по ссылке.
Итак, зная какой механизм отладки у нас подключен идем на сервер 1с и открываем редактор реестра windows:
Далее по ветке “HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservices” и находим там каталог с агентом сервера 1с: “1C:Enterprise 8.3 Server Agent (x86-64)”:
И в параметре ‘ImagePath’ добавляем свойство: -debug:
После изменений в реестре, необходимо перезагрузить сервер 1с – и наслаждаться отладкой!
Читайте также: