Берём самый залайканый, и дальше не читаем))) А вообще  тут вопрос, зачем тебе где-то понадобилось вообще это, кроме как на старте приложения, в одном месте можно выбрать, там configuration builder, вроде как, рекомендуют в msdn

нене, я про вызовы конструктора. На самом деле я неправильно сформулировал....

моя основная претензия такая: DI не ловится на этапе компиляции.

Вот ты добавил депенденси-сервис. И у твоего конструктора класса (который юзает этот сервис) должна быть определнная сигнатура. ДОЛЖНА быть. Но если не будет - да и похер, код все равно скомпилится

Это проблема, согласен. То, что это ловишь в runtime - такое себе.

Да, с последней проблемой согласен

Ой а у нас в пхп нет такой проблемы 🙂

Нам правда и компилить не надо 😅

Нет проблемы разбираться с сообщениями компилятора?! Всё, ухожу в php 🤣

Не, он фатал выдаст

Скажет что сигнатура не та

Ребят, а blazor (webassembly) в продакшн никто не использует?

Эх, смена стека  отменяется.

Я для того, чтобы в рантайме не ловить - тест пишу и новые высокоуровневые компоненты (контроллеры, инфраструктурные сервисы) туда добавляю. Ну или можно каждому крупному компоненту в числе прочих написать тест, что он из контейнера поднимается.

Тест что делает? Пытается получить экземпляр типа?

Да

При этом происходит инициализация startup, и всякие окружающие вещи, типо БД мокаются? Разработчик должен помнить, что при добавлении типа, ему нужно добавить его в тест ручками? Или используется интерфейс маркер, и через рефлексию проверяем возможность получения соответствующего типа или интерфейса?

Разверну мысль: хочу отметить это и все что ниже как не прочитанное, когда пишешь ответ на сообщение в середине - весь хвост отмечается как прочитанный…

По идее для этого теста достаточно написать мок AppConfig. Если этого недостаточно - вероятно, что-то не так в архитектуре. Никакой startup не нужен, все конструкторы должны только инициализировать свойства и больше не делать ничего, db.New(AppConfig.DBConfig()) и db.Connect() - это разные методы.

Можно, кстати, и написать general-тест, который ходит и через рефлексии проверяет, что все сущности из контейнера поднимаются. У меня всё равно уже есть один такой, который проверяет, что доменный слой не зависит от прикладного.

Хорошая идея, попробую реализовать!

Понял. Спасибо, тоже возьму на вооружение!

Пишешь ответ и потом жмёшь на оригинал сообщения. И читаешь дальше