Вызов AddMediatR
в вашем файле startup.cs
делает много вещей для инициализации MediatR.
Одна из тех вещей, которые он выполняет, сканирует домен приложений на наличие загруженных в данный момент сборок. После этого он будет сканировать эти сборки, чтобы найти все классы, которые наследуются от базовых типов MediatR (IRequestHandler
, INotificationHandler
, IRequestPreProcessor
и IRequestPostProcessor
), а затем зарегистрировать их для использования в MediatR.
Имея это в виду, важно понимать, как .NET CLR загружает ссылочные сборки. Здесь есть действительно интересное сообщение в блоге Рика Стрэла, в котором подробно рассказывается, но я суммирую его здесь цитатой:
Короче говоря, ссылочные сборки загружаются не сразу, а по мере необходимости. Поэтому независимо от того, есть ли у вас ссылка на сборку в проекте верхнего уровня или зависимые сборки, как правило, загружаются по мере необходимости, если явно не загружен пользовательским кодом. То же самое относится и к зависимым сборкам.
Почему это важно знать?
Что ж, в вашем проекте MyApi2
вы ссылаетесь на проект MyInfra
, но фактически не используете его. Это означает, что сборка не будет загружена CLR, и, следовательно, MediatR не сможет найти ее в загруженных сборках домена приложения. В результате ваш IRequestHandler
не будет зарегистрирован.
Чтобы решить эту проблему, у вас есть несколько вариантов, я назову пару ниже:
Вы можете вручную загрузить вашу сборку до , вызывая AddMediatR
в вашем файле startup.cs
.
Или
Вы можете вызвать какую-то функциональность, которая находится в вашем MyInfra
проекте до вызова AddMediatR
в вашем файле startup.cs
.
Последний вариант является наиболее типичным, так как у вас обычно есть некоторые функции, которые находятся в вашей сборке, на которую вы хотите ссылаться (в отличие от просто наличия сборки, содержащей типы).