Если у вас есть библиотечный код, который нуждается в службах, и этот код может быть размещен в контексте более широкой среды исполнения / среды выполнения, тогда среда / среда исполнения должна будет предоставить механизм, позволяющий запускать некоторый пользовательский код при запуске, в котором вы можете инициализировать ваш контейнер и зарегистрируйте зависимости. Хорошим примером того, где CSL может быть проблематичным, является использование его в контексте MSCRM. Вы можете настроить собственную бизнес-логику, зарегистрировав плагины, которые MSCRM-среда выполняет для определенных событий. Проблема, с которой вы сталкиваетесь, заключается в том, где вы запускаете логику регистрации, поскольку нет события «запуска», на которое вы можете подписаться для настройки вашего DI-контейнера. Даже если бы вы могли как-то настроить свой DI, вам нужно было бы поместить библиотеки CSL и DI в GAC, поскольку это единственный способ вызвать сторонний код из плагина (еще один элемент, который нужно добавить в контрольный список развертывания). В таких сценариях вам лучше иметь свои зависимости в качестве параметров конструктора, которые вызывающий код может инициализировать по своему усмотрению (либо путем внедрения конструктора, либо вручную «обновляя» соответствующую реализацию интерфейса).

трел наОбщий Сервисный Локатор [http://commonservicelocator.codeplex.com/]как способ абстрагирования моего контейнера IoC, но я заметил, что некоторые люди категорически против этого типа этого. Люди рекомендуют никогда не использовать это? ...