Ну да, не для этого докер придумывали, но уж больно просто все получается. Плюс воспроизводимость билда любой машине. Плюс простота обновления зависимостей, просто измени базовый образ.
Для отладки CompletionProvider проще всего использовать шаблон в VS «Analyzer with code Fix». Создать проекты по шаблону, после чего запускать проект Vsix. Он буде загружать новую студию с подключенным CompletionProvider как расширение, в котором можно нормально отлаживать.
Как по мне это очень долгий способ дебага. Чтобы подкрыть 99% ситуаций будет достаточно написать тесты, которые прогонят ваш анализатор на нужных кусках кода и проверят что получилось в итоге.
Дело в том, что очень часто, тот кто говорит на суржике может усилием воли «сдвинуть» свою лексику в нужную сторону. Например, перед тобой человек который не говорит на украинском, но знает русcкий, следовательно, нужно использовать только русcкие слова, ну и на оборот. После небольшой практики это вообще делается подсознательно. Но если нужно что-то сказать быстро, то могут проскакивать украинские слова и граматические конструкции. В моей практике, на уровень общения/понимания это никак не сказывалось.
Думаю еще нужен режим «Само уничтожаемое двойное дно». Это когда ты вводишь определенный пароль, открывается дефолтный аккаунт, а «двойное дно» уничтожается.
Как технический специалист ты не должен следить за «отраслевым знанием» у тебя своего собственого «отраслевого знания» вагон и маленькая тележка. Следить сразу за двумя не получится просто физически, в итоге ты будешь плох в двух областях сразу. Для отслеживания «отраслевого знания» есть другие люди. Они живут им и следят за его изменениями постоянно, это часть их жизни. Обычно это сами заказчики или консультанты, но уж точно не программисты.
Это утверждение подтвержается на практике. Это не вера. Например, если у вас несколько мест откуда можно брать данные, логично сделать их отдельными сервисами вместо того чтобы городить какой-нибуть switch.
В случае с медиатр вы видите красивое IMediatr, контроллер до сих пор делает кучу вещей, только это абсолютно не очевидно.
В случае с медиатр все очевидно, контролер не делает ничего связаного с бизнес логикой. За нее отвечает медиатр и для каждого отдельного вызова будут свои собственые зависимости, которые можно посмотреть в обработчике для медиатр.
MediatR позволяет локализовать проблему. Пускай у нас будет один роут с 6+ зависимостями, а не 10 роутов с 10+, только из-за того, что они случайно оказались в одном контролере.
Ну да, не для этого докер придумывали, но уж больно просто все получается. Плюс воспроизводимость билда любой машине. Плюс простота обновления зависимостей, просто измени базовый образ.
А потом артефакты копируются в другой image в котором только рантайм или вообще чистый дистрибутив, если деплоить как self-hosted.
Update: А теперь все заработало.
Как по мне это очень долгий способ дебага. Чтобы подкрыть 99% ситуаций будет достаточно написать тесты, которые прогонят ваш анализатор на нужных кусках кода и проверят что получилось в итоге.
А до этого чем вы занимались?
Написано конечно класно, но заголовок не соотвестувет содержанию.
В случае с медиатр все очевидно, контролер не делает ничего связаного с бизнес логикой. За нее отвечает медиатр и для каждого отдельного вызова будут свои собственые зависимости, которые можно посмотреть в обработчике для медиатр.