Отладка в D365FO

[sukhanchik]

Всем привет!
Хочу зафиксировать то, с чем пришлось недавно столкнуться и с чем столкнулись многие, кто уже работает с D365FO, но что для новичков может быть будет интересно. Речь идет об отладке в Visual Studio.
Отладка в D365FO производится в Visual Studio путем присоединения (attach) студии к процессу. В момент отладки другие пользователи работать с системой не могут (сайт висит белым экраном).

Соответственно, как мы добираемся до отладчика:
Предварительная настройка

• Необходимо убедиться, что в параметрах отладки установлен путь к отладочным символам в каталог, где лежат модели Вашего приложения (у меня это C:\AOSService\PackagesLocalDirectory)
• Необходимо убедиться, что указан путь к кэшу символов. Туда будут копироваться отладочные символы из источников. Для ускорения загрузки символов иногда указывают в роли папки кэша папку источник (ту же C:\AOSService\PackagesLocalDirectory), однако на мой взгляд не стоит этого делать, т.к. если Вам в дальнейшем захочется как-то скопировать эти папки с моделями или проанализировать каталог – то данные кэша будут мешаться.

Расстановка точек останова
Хорошо, когда есть возможность запустить код на исполнение сразу из студии (например, исполняемый класс (Runnable class)), но если надо провалиться в отладчик прямо из формы, то форму сначала нужно запустить в обозревателе и поставить точки останова в студии. Ищем нужную строку и жмем кнопку F9 или выбираем меню Debug-Toggle Breakpoint. В данном случае мы поставили точку останова на форме заказов на покупку (PurchTable)


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


Присоединение
Идем в студию и выбираем пункт меню Debug-Attach to Process…

Вот теперь и начинаются различия.

• До версии 7.3 PU12 (а также в локальных виртуалках с демо-данными) необходимо было выбирать процесс w3wp.exe, для чего устанавливать флажок Show processes from all users и запускать предварительно студию с правами администратора
  
  
• После версии 7.3 PU12 в тех облачных средах, где отобрали права администратора добавили такую штуку, как IIS Express. Он визуально выглядит, как дополнительный значок в трее. При входе в студию (без повышенных прав администратора) останавливается служба World Wide Web Publishing Service (та самая w3wp.exe, к которой мы подключались до этого) и стартует IIS Express. Само собой, сайт, который хостится на этой службе падает, хотя и поднимается на IIS Express. В принципе это незаметно ровно то тех пор, пока со средой работает только один разработчик (как того и требует МС). Соответственно присоединяться мы будем уже не к w3wp.exe, а к iisexpress.exe и этот процесс будет висеть в процессах пользователя (флажок Show processes from all users устанавливать не потребуется)

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

Такая картинка говорит о том, что отладочные символы для данной точки останова не загрузились и либо они дозагрузятся, когда мы откроем форму, либо их надо вручную дозагрузить. Я предпочитаю загружать все символы, т.к. они один раз загрузятся и больше потом кнопка Load All не будет тормозить (если конечно не будет удален кэш файлов). Бывает конечно что подтормаживает, но в целом по моему субъективному мнению процесс загрузки ускоряется. В интернете я находил способы частичной загрузки, но как-то они у меня нестабильно работали. Иногда бывает, что надо отсоединиться (меню Debug-Stop debugging) и снова подсоединиться.



После успешной загрузки символов точка останова "краснеет":


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

Следует обратить внимание на разницу пунктов меню между Debug-Stop debugging (или DetachAll) и Debug-Terminate All.


В последнем случае прекращается исполнение кода, в то время как в первых вариантах студия всего лишь отцепляется от исполнения кода, а код продолжает исполняться (Stop debugging – остановка отладки, но это не остановка выполнения кода)

Тоже самое для процесса w3wp.exe


Еще маленькое дополнение к IIS Express. Если в силу ряда причин хочется отказаться от использования IIS Express и вернуться к старому доброму IIS (а также хочется, чтобы при открытии студии сайт не падал при переключении с IIS на IIS Express), то можно в файлике C:\AosService\PackagesLocalDirectory\Bin\DynamicsDevConfig.xml заменить значение параметра RuntimeHostType с IISExpress на IIS (само собой после этого нужен рестарт IIS). После этого для отладки нужно будет подключаться к процессу w3wp.exe


Забыл добавить. Версия, на которой все показывалось - 8.0 PU 15

[Ivanhoe]

Насчет "сайт висит белым экраном" - это при использовании одного сервера для всех пользователей или вообще в принципе, не зависимо от количества серверов?

[sukhanchik]

Quote:

Originally Posted by Ivanhoe

Насчет "сайт висит белым экраном" - это при использовании одного сервера для всех пользователей или вообще в принципе, не зависимо от количества серверов?

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

[Ivanhoe]

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

Если перенести аналогию на Dyn365FO - все курят бамбук независимо от количества серверов в инсталляции, или аналогично с 2012 - курят бамбук только пользователи одного IIS?

[sukhanchik]

Теперь понятно, спасибо. Сейчас все проще. AOS один и он называется IIS. Служба, обрабатывающая пакетные задания - Batch. Сайт называется AOSService, база - AxDB. Ну т.е. несколько IIS-ов на одной машине не развернешь ).
Не знаю, как в варианте On-Premise, потому что теоретически можно наверное какой-нибудь кластер серверов развернуть и тогда, безусловно будет лочиться IIS только какого-то одного сервера.
Но в облачном варианте студия на проде и тесте исключена как класс. Т.е. предполагается, что каждый разработчик имеет свою локальную виртуалку и ходит на дев-приложение только для целей сборки кода от разных разработчиков.
На облачный прод даже доступа нет ) от слова совсем . С него можно только попросить инженеров МС снять копию БД, а на него можно накатить пакадж программного кода

[fed]

Quote:

Originally Posted by sukhanchik

Не знаю, как в варианте On-Premise, потому что теоретически можно наверное какой-нибудь кластер серверов развернуть и тогда, безусловно будет лочиться IIS только какого-то одного сервера.

В On Premises отлаживаться не получается. Во первых - там нет IIS в принципе. Есть Service Fabric, которое как-то и куда-то грузит assembly аксапты и как-то организует Web interface к ним. Во вторых - нету никакой документации о том как отлаживать там код Ax. То есть - теоретически имеется возможность отлаживать контейнеры Service Fabric, но аксаптовского tooling'а для этого нет. (да и как мне кажется, отладка может идти только в урезанной локальной версии Service Fabric, на которую Аксапту не установить...)

[AlexeyS]

и это только для отладки? чОрт побери ...

[belugin]

1) Для отладки можно поставить точку останова не загружая форму, просто поставить в VS (я, правда, работаю в основном с формами из проекта)

2) На скриншоте показывается настроенная загрузка символов "все, кроме перечисленных", я обычно выставляю в "только перечисленные" - там можно выбрать модуль со звездочками, например *ElectronicReporting*

3) Есть настройка Dyn365FO "загружать символы только в проекте", я обычно ее отключаю.

4) Есть окно "Modules", в котором можно загрузить символы для модуля уже в процессе отладки

[skuull]

Quote:

Originally Posted by sukhanchik

Но в облачном варианте студия на проде и тесте исключена как класс.

Что не отменяет возможности дебижать тест не имея студии на нем https://docs.microsoft.com/en-us/dyn...-of-production

[belugin]

Quote:

Originally Posted by fed

То есть - теоретически имеется возможность отлаживать контейнеры Service Fabric, но аксаптовского tooling'а для этого нет.

Теоретически, можно отлаживаться без аксаптовских тулов, например есть dnSpy (не знаю, правда, разрешено ли это лиценнзией AX). Вопрос удобства. Надо чтобы были символы и доступ к процессу. Для VS надо еще исходники или хорошее знание IL Исходники надо в формате XPP.

[pitersky]

Я бы ещё дописал, что
1) для отладки пакетов надо аттачиться к отдельному процессу Batch
2) чтобы дебажить джобы - нужно кликать на Debug/ Start without debugging. Предварительно указав джоб как Set as Startup object

[sukhanchik]

Quote:

Originally Posted by belugin

1) Для отладки можно поставить точку останова не загружая форму, просто поставить в VS (я, правда, работаю в основном с формами из проекта)

2) На скриншоте показывается настроенная загрузка символов "все, кроме перечисленных", я обычно выставляю в "только перечисленные" - там можно выбрать модуль со звездочками, например *ElectronicReporting*

3) Есть настройка Dyn365FO "загружать символы только в проекте", я обычно ее отключаю.

4) Есть окно "Modules", в котором можно загрузить символы для модуля уже в процессе отладки

По некоторой старой привычке хочется, чтобы отладка работала полная, а не только по модулям. Потому что иногда иногда фиг знаешь до какого кода дойдешь. Пробовал я по модулям, но для себя решил, что мне будет проще жать Load all. Дело в том, что отладка - это не какое-то из ряда вон событие, а регулярная процедура, которую выполняет разработчик. Причем, если он уж полез в отладку, то он ее запустит как правило не один и даже не пять раз. А значит на одной чаше весов лежит время, а на другой - уменьшение кол-ва кликов мышкой. В результате я пришел к Load all, как к самому для меня оптимальному решению.

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



Флажок "загружать символы в проекте" я не трогал, а вот "только мой код" - менял - иначе с ней можно не провалиться в код вне проекта. А вот без нее проваливаешься, но периодически и получаешь какие-то C#-ные вызовы, по которым отладчик тоже проходит. Поэтому я ее туда-сюда ставлю .

Про окно Modules я тоже читал - в статье советовали загрузить к примеру модуль Ledger при отладке в финансовом контуре. И это работает. Но это еще надо догадаться, какой модуль загрузить . Иногда модуль можно не угадать и тогда время, потраченное на эту процедуру сильно возрастает перед обычной кнопкой Load all. Ну а как я уже писал - отладка - это не самоцель - это инструмент и когда хочется его использовать - хочется это сделать минимальными усилиями, чтобы не отвлекаться от основной мысли.

[sukhanchik]

Quote:

Originally Posted by skuull

Что не отменяет возможности дебижать тест не имея студии на нем https://docs.microsoft.com/en-us/dyn...-of-production

А мне вот этот момент интересен. Его уже практическим путем кто-нибудь проходил? Или пока только ссылку видели?

Я из схемки и описания понял, что дебажится БД теста, но приложение берется с дева и сама отладка идет с дева, при этом дев останавливается (просто он перенацеливается на базу теста). Я неправильно понял?

[belugin]

Quote:

Originally Posted by sukhanchik

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

Модуль можно найти в AOT

[sukhanchik]

Quote:

Originally Posted by pitersky

Я бы ещё дописал, что
1) для отладки пакетов надо аттачиться к отдельному процессу Batch
2) чтобы дебажить джобы - нужно кликать на Debug/ Start without debugging. Предварительно указав джоб как Set as Startup object

Да, спасибо - про Batch я как-то упустил из виду. А для джобов да - там такая ситуация:
Нужно указать Startup project (если у вас в Solution несколько проектов) - это проект, в котором находится запускаемый класс

Нужно указать Startup object в проекте или свойствах проекта - это сам запускаемый класс.

В свойствах проекта

Еще можно указать как сам Startup object, так и раздел и компанию, в которой его необходимо запустить


И после этого уже жать заветную зеленую кнопку

[Vadik]

Quote:

Originally Posted by sukhanchik

А мне вот этот момент интересен. Его уже практическим путем кто-нибудь проходил? Или пока только ссылку видели?

Я из схемки пока только понял, что дебажится БД теста, но приложение, которое хранится в VSTS (и которое синхронизировано с девом). Я неправильно понял?

Дебажится текущее приложение в DEV подключенное к БД на TEST. Если в TEST деплоите регулярно и большой рассинхронизации по структуре БД между DEV и TEST нет - рабочий вариант если надо что-то срочно посмотреть. Но мы все равно bacpac-и из TEST в DEV регулярно (не реже раза в месяц) гоняем

[fed]

Quote:

Originally Posted by sukhanchik

А мне вот этот момент интересен. Его уже практическим путем кто-нибудь проходил? Или пока только ссылку видели?

Я из схемки пока только понял, что дебажится БД теста, но приложение, которое хранится в VSTS (и которое синхронизировано с девом). Я неправильно понял?

Кстати, Микрософт анонсировал что скоро у партнеров отберут терминальный доступ TEST инстансу. (Поскольку их для экономии средств переведут в Service Fabric, где на одном VM могут инстансы разных клиентов крутится). Так что копать в сторону установки VS или какого-то внещнего отладчика в TEST - бесполезно. Скоро это станет неактуальным. (Правда Микрософт обещает оставить доступ к Test DB через SQL Management studio и сделать копирование базы данных из TEST в DEVTEST по кнопочке из LCS).
Но в целом - то что в статье описано - это такой хак для того чтобы можно было отлаживать приложение в DEVTEST, не дожидаясь переливки данных из TEST в DEVTEST.

[sukhanchik]

Понятно, спасибо за информацию - будем привыкать к новым реалиям

[skuull]

Quote:

Originally Posted by fed

Кстати, Микрософт анонсировал что скоро у партнеров отберут терминальный доступ TEST инстансу. (Поскольку их для экономии средств переведут в Service Fabric, где на одном VM могут инстансы разных клиентов крутится).

А можно ссылочку ?

[fed]

Quote:

Originally Posted by skuull

А можно ссылочку ?

Про отнятие RDP-доступа писали здесь: https://blogs.msdn.microsoft.com/lcs...-subscription/
Про Service Fabric и доступ к SQL Management studio писали где-то в яммере.
P.S. Писали здесь: https://www.yammer.com/dynamicsaxfee...ads/1040155537