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

[Артем 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 тут бы конечно помог, но проект походу сдох.