Общие (сторонние) библиотеки в плагинах

[ZooY]

Коллеги, поделитесь опытом, кто как использует общие или сторонние библиотеки в плагинах.
Например, у меня есть библиотека, используемая во всех плагинах.
Раньше я сливал ее с помощью ILMerge с плагином и плагин как обычно заливался регистратором. Все отлично работало.
Потом понадобилось журналирование, заюзал log4net, который в слитом виде работал некорректно. Пришлось вынести log4net в GAC, а заодно туда же и общую библиотеку.
Но чего то работой с GACом я "наелся", потому что разработка и отладка плагина, когда требуется внести правки в общую библиотеку, превращается в незапланированный бардак с постоянными iisreset-ами и перезаливками в GAC. C ILMerge в этом плане не было вообще никаких проблем.

Кто как решает подобные задачи?

[a33ik]

Только IlMerge, только хардкор.
Парктически все проекты, с которыми работаю - облако, так что GAC и файловая система - недоступны.

Можете поделиться - в чём проблема с log4net и мёржем? Я буквально на той неделе работал с FileHelpers библиотекой - проблем не выявлено.

[ZooY]

Проблема с log4net какая то странная... Он не может создать логгер, пишущий в базу данных. Какие то проблемы к классом ADO.NET, каким точно не помню. Файл настроек для log4net лежит в CRM как XML-веб-ресурс, вот yf этапе его загрузки в логгер все и падает. Тот же самый код в сервисах работает.

[a33ik]

Если честно - зачем вам такие сложности? Не проще ли вынести такого рода функционал в сторонний сервис и просто его вызывать?

[ZooY]

Цитата:

Сообщение от a33ik

Не проще ли вынести такого рода функционал в сторонний сервис и просто его вызывать?

Какого рода функционал?
Логирование? Но тогда его надежность сильно ниже, наверное будет, когда логгер где то там, далеко в стороннем сервисе.
Общая бизнес-логика? Это точно прямое воздействие на производительность. Одно дело что-то сделать прямо в плагине и совсем другое дернуть сторонний сервис, подождать ответа... Конечно, с точки зрения простоты реализации это гораздо удобнее.

[a33ik]

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

[ZooY]

Внезапно обнаружилось...
При сливании с помощью ILMerge плагина и log4net не удается сконфигурировать AdoNetAppender с помощью XML-файла - получаю ошибку

Цитата:

Could not create Appender [AdoNetAppender] of type [log4net.Appender.AdoNetAppender]. Reported error follows. CreateConverterInstance cannot create instance, converterType is null
Parameter name: converterType
Appender named [AdoNetAppender] not found.

При этом, кстати, FileAppender прекрасно конфигурировается.
Однако, если создать тот же самый AdoNetAppender программно - то все работает.
Как вариант можно вручную парсить XML, хотя, конечно, это дико муторно.

[Артем Enot Грунин]

Что-то поздно я увидел ваш пост. По поводу мержевания, однозначно рекомендую ILRepack, так как с ILMerge я знатно наелся говна.

Что касается логирования, то тут два вопроса/замечания:

1. Чем плох стандартный TraceService?
2. Я бы не стал реализовывать его в своем коде

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



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

[ZooY]

Цитата:

Сообщение от Артем Enot Грунин

Чем плох стандартный TraceService?

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

Цитата:

Сообщение от Артем Enot Грунин

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

В моем случае, лог нужен не для того, чтобы он просто был или для мониторинга доступности системы/функционала, а для отладки и тестирования. Так что его прием и хранение - это моя проблема

[Артем Enot Грунин]

Цитата:

Сообщение от ZooY

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

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

Цитата:

Сообщение от ZooY

В моем случае, лог нужен не для того, чтобы он просто был или для мониторинга доступности системы/функционала, а для отладки и тестирования. Так что его прием и хранение - это моя проблема

Тоже довольно странная практика... Почему для отладки и тестирования нельзя использовать Unit тесты? Тот же Fake Xrm Easy позволяет вам даже запросы к базе протестировать. На худой конец есть Плагин Профайлер... Ну или CRMSnoop, который соберет за вас трассировку

[ZooY]

Цитата:

Сообщение от Артем Enot Грунин

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

Общая трассировка, включаемая через реестр, по прежнему пишется в файл.
Трассировка плагинов, которая должна писаться в Plug-in Trace Log у меня лично туда не пишется. Системная настройка, говорящая о записи всего-всего - стоит, а записей нет. Возможно это работает в Online-версии CRM, но у меня на OnPremise - не работает.

Цитата:

Сообщение от Артем Enot Грунин

Тоже довольно странная практика... Почему для отладки и тестирования нельзя использовать Unit тесты? Тот же Fake Xrm Easy позволяет вам даже запросы к базе протестировать. На худой конец есть Плагин Профайлер... Ну или CRMSnoop, который соберет за вас трассировку

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

[Артем Enot Грунин]

Понял вас, резон есть. Добавлю только, что мы подобное тоже практикуем и производительность в жопе. Возможно, конечно, все дело в реализации, но дисковые операции существенно тормозят пайплайн.

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

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

1. Не придется ничего мержить в основные сборки
2. Они могут работать в песочнице, так как не нужен доступ к файловой системе, или БД
3. Вы можете централизованно управлять реализацией логирования, его глубиной и т.д.