Как вы имитируете IUnityContainer?

Вы этого не сделаете.

Единственная причина издеваться над контейнером - это если вы его передаете. Это антипаттерн.

Вместо этого вы хотите составить весь граф объектов в точке входа приложения или Composition Root < / а>.

Если вам нужно создавать экземпляры на лету, используйте Автоматические фабрики.

Для своих тестов вы можете либо сконструировать тестируемый объект и передать фиктивные объекты конструктору, либо создать новый контейнер в тесте и зарегистрировать в нем фиктивные объекты.

Вы пробовали издеваться над UnityBaseContainer или UnityContainer вместо IUnityContainer, ala этот пост Рори Примроуз? Он имеет дело с RhinoMocks, но поскольку я думаю, что проблема связана с внутренним использованием Moq Castle, вы можете решить проблему таким образом.

Вам нужен полноценный макет объекта? Не могли бы вы обойтись простым внедрением фейка? То есть, реализовать тестовый экземпляр интерфейса IUnityContainer и переопределить метод, с которым вам нужно взаимодействовать?

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

Из-за этой проблемы я не высмеиваю IUnityContainer, я вместо этого использую реальный экземпляр UnityContainer. Это не идеально, но я могу протестировать регистрацию, убедившись, что контейнер может разрешать типы соответствующим образом.

Вы можете имитировать и использовать IServiceLocator, когда вы используете его для определения типов в ваших классах, или, что еще лучше, использовать регистрацию фабрики в контейнере и использовать ее вместо этого.

Вы используете это на Win x64? Взгляните на эту страницу. Это явно наводит на мысль.

Это исключение возникает, когда формат файла библиотеки динамической компоновки (файл .dll) или исполняемого файла (файл .exe) не соответствует формату, ожидаемому средой CLR.