Используя NHibernate 3.1 и Moq 4.0.10827 в моих модульных тестах, все это работает в .NET 4.0, я получаю следующую ошибку, если все тесты выполняются один за другим в одном и том же домене:
NHibernate.HibernateException: создание экземпляра прокси не удалось
----> System.InvalidCastException: невозможно преобразовать COM-объект типа «System .__ ComObject» в интерфейс типа «Microsoft.Runtime.Hosting.IClrStrongName». Эта операция завершилась неудачно, поскольку вызов QueryInterface для компонента COM для интерфейса с IID '{9FD93CCF-3280-4391-B3A9-96E1CDE77C8D}' завершился ошибкой из-за следующей ошибки: Интерфейс не зарегистрирован (Исключение из HRESULT: 0x80040155).
Эта ошибка не дает сбоя, когда я запускаю тесты, которые используют Moq отдельно от тех, которые этого не делают.
Интересно, что, когда у меня все еще была версия Moq .NET 3.0, я получал похожую ошибку cast COM object...
, когда выполнял серию тестов Moq. С тех пор я перешел на 4.0 версию Moq.
Некоторые сведения об этой ошибке (смотрите в нижней части раздела «Устранение неполадок»):
http://blogs.msdn.com/b/clrteam/archive/2010/06/23/in-proc-sxs-and-migration-quick-start.aspx
В частности, он говорит:
Если ваше приложение создает экземпляры COM и использует компоненты COM через уровень управляемых взаимодействий .NET Runtime, и один из этих компонентов COM оказывается управляемым, то существует небольшая вероятность того, что после миграции приложения вы можете столкнуться с ошибкой, аналогичной [ошибка выше].
Эта ошибка может возникать в результате следующих двух комбинированных условий:
Управляемый COM-компонент зарегистрирован в версии .NET Runtime, отличной от версии экземпляра вызывающей стороны, в результате чего он будет активирован во время выполнения, отличном от версии экземпляра вызывающей стороны.
Интерфейс не помечен как System.Runtime.InteropServices.ComVisibleAttribute со значением true.
Этот сценарий работал в прошлом из-за оптимизации времени выполнения: когда среда выполнения .NET замечает, что создаваемый ею COM-тип имеет управляемую реализацию, и что он был создан в том же домене приложения, что и вызывающий экземпляр, он обходит Уровень управляемого взаимодействия и возвращает вызывающему объекту сам управляемый объект. В предыдущих выпусках .NET Framework (где S-Sx в рамках процесса не был доступен) все управляемые типы COM и их управляемые клиенты обычно загружались в один и тот же домен приложения, что позволяло возвращать реализуемый управляемый объект и, в свою очередь, разрешать приведение интерфейса. преуспеть, не будучи отмеченным как ComVisible.
Миграция приложения может легко создать условие 1; если приложение также опирается на условие 2 (которое встречается гораздо реже), то возникнет указанная выше ошибка. Есть несколько доступных решений:
Получите обновленную версию управляемого типа COM, которая должным образом объявляет интерфейс как ComVisible.
Обновите файл конфигурации приложения для использования расширения useLegacyV2RuntimeActivationPolicy.
Кажется, что они могут быть чем-то в .NET 4, что не нравится Castle DynamicProxy? Я нашел сообщение в списке рассылки Castle , которое намекает на это.
Я попытался использовать переключатель useLegacyV2RuntimeActivationPolicy="true"
в app.config сборки модульного теста (ReSharper 6). Я также попробовал тот же самый переключатель в родном средстве запуска NUnit.
Есть идеи?