Лучше всего спроектировать ваше приложение на основе внедрения зависимостей (конструктор) и настроить контейнер на пути запуска (корень композиции) вашего приложения.В идеале, ваш проект B не должен зависеть от самого контейнера DI, или, самое большее, иметь некоторый загрузочный код в проекте, который позволяет создавать конфигурацию для этого проекта.
Когда вы регистрируете контейнер в стартовом проекте(возможно, проект А в вашем случае) у вас не будет круговой ссылки.
ОБНОВЛЕНИЕ
В комментариях вы пояснили, что ваш проект Проекта B предназначен исключительно для МОКсамонастройки.В загрузочном проекте нет ничего плохого, потому что это позволит вам полностью очистить все другие проекты от использования любого контейнера IOC.Обычно вы используете проект начальной загрузки, если у вас есть несколько библиотек, которые повторно используются несколькими приложениями (например, бизнес-уровень, используемый веб-приложением, веб-службой и службой Windows).
Проект начальной загрузкиоднако следует только загружать «статические» зависимости многократно используемых проектов.Нет смысла настраивать вещи, которые меняются в зависимости от проекта приложения.Далее, поскольку загрузчик сам по себе является многократно используемым проектом, вы не хотите, чтобы он зависел от одного из ваших проектов приложения, поскольку это будет та часть, которую вы будете менять.Какая польза от ссылки на веб-приложение ASP.NET при запуске службы Windows?Это было бы отвратительно.
Проект начальной загрузки особенно полезен при наличии нескольких проектов приложений, но это не означает, что вы не можете использовать его в одном приложении.Тем не менее, здесь применяются те же правила, поскольку, как вы уже заметили, вы получите циклические ссылки.
Другими словами, решение простое: пусть загрузчик загружает только зависимости для проектов ниже, а не приложения.проект.Однако, если проект приложения - единственный проект, который у вас есть, вам не нужен проект начальной загрузки;это не сработает.