У меня есть проект библиотеки .NET с около 500 модульных тестов. Все эти тесты работают нормально в Visual Studio 2012. Однако некоторые из моих тестов не проходят в Visual Studio 2010. В этих тестах, которые я провалю, я используюMoq высмеивать несколько типов взаимодействия изMicrosoft.Office.Interop.Excel, Тест сразу завершается неудачно при попытке доступа к этим типам взаимодействия:

Error: Missing method 'instance class Microsoft.Office.Interop.Excel.Range [ExcelAddIn.Core] Microsoft.Office.Interop.Excel.ListRow::get_Range()' from class 'Castle.Proxies.ListRowProxy'.

Это исключение подразумевает, что я забыл установить соответствующий метод получения свойства на макете. Что не так:

_listRowMock.Setup(m => m.Range).Returns(_rangeMock.Object);

Теперь я могу представить, что Moq может не очень хорошо работать с Interop Types. Но больше всего меня удивляет то, что эти тесты нормально работают в Visual Studio 2012, но не работают в Visual Studio 2010.

Почему моя Visual Studio влияет на поведение моего кода?

ОБНОВЛЕНИЕ: 3-11-2012

Итак, я поняла это:

У меня есть два проекта; Core и Core.UnitTest. Core - это настоящая библиотека, а Core.UnitTest - это проект модульного тестирования библиотеки Core.Оба проекта ссылаются на Microsoft.Office.Interop.Excel со встроенными типами взаимодействия.Поскольку EIT включен, оба проекта включают своиПосмотреть" библиотеки Microsoft.Office.Interop.Excel. Представление включает в себя все классы, методы и свойства, которые используются в соответствующем проекте.Поскольку оба проекта используют разные классы, методы и свойства Microsoft.Office.Interop.Excel, встроенные типы обеих библиотек различаются. Например. ListRow в Core имеет свойство Index и Range, тогда как ListRow в Core.UnitTest имеет только свойство Range.Хотя оба типа различны и не имеют общего интерфейса или суперкласса, ониэквивалент, Это означает, что CLR будет обрабатывать их, как если бы они были одинаковыми, и позволит вам использовать эти типы через границы сборки. Например. экземпляр ListRow из Core.UnitTest будет нормально работать при передаче методу в библиотеке Core. Общее свойство Range будет работать, тогда как отсутствующее свойство Index вызовет исключение MissingMethodException при доступе.Вышеупомянутое поведение работает даже с поддельными типами. Пересеченный объект Mock [Excel.ListRow] будет нормально работать при пересечении границы сборки.К сожалению, поведение, описанное в предыдущем пункте, работает только при сборке моих сборок в Visual Studio2012, Когда я собираю свои сборки в Visual Studio2010 и отладить мой код, я вижу, как смоделированный экземпляр ListRow передается в метод моего основного проекта. В тот момент, когда экземпляр пересекает границу сборки, все методы и свойства ListRow теряют свою реализацию и выдают исключения MissingMethodException.Теперь для забавы, мне действительно удалось смягчить эту проблему, обеспечив выравнивание обоих встроенных типов ListRow. Например. для того, чтобы компилятор создал одинаковое представление ListRow в обоих проектах, я убедился, что использовал те же методы и свойства в своем проекте UnitTest. Это означает добавление фиктивных строк, таких как: var dummy = listRow.Index. Как только у меня был компилятор, создававший идентичные представления моего встроенного типа ListRow, экземпляру было разрешено пересекать границы сборки без потери его реализации.

Однако все еще остается вопрос: что вызывает эту разницу в поведении между Visual Studio 2010 и Visual Studio 2012?

ОБНОВЛЕНИЕ: 9-11-2012

Демо-решение:http://temp-share.com/show/KdPf6066h

Я создал небольшое решение, чтобы продемонстрировать эффект. Решение состоит из библиотеки и проекта UnitTest. Оба ссылаются на Microsoft.Office.Interop.Excel.Range с включенным EIT. Тест отлично работает в VS2012, но выдает исключение MissingMethodException в VS2010. Раскомментирование фиктивной строки в тесте заставит его работать в VS2010.

ЗАКЛЮЧИТЕЛЬНОЕ ОБНОВЛЕНИЕ: 29-12-2012

Мои извинения за позднее обновление. Мой коллега нашел решение, но я не смог воспроизвести его на своей машине. Тем временем наша компания перешла на TFS2012, так что это больше не проблема для меня. Два наиболее важных вывода, которые сделал мой коллега, были следующими:

Семантика "Любой процессор " Платформа была изменена с Visual Studio 2010 на Visual Studio 2012. Это приведет к другому .DLL 'генерируется в зависимости от того, используете ли вы VS2010 или VS2012.Оба проекта ссылались на разные версии Microsoft.Office.Interop.Excel.

Я проверил свои проекты и выровнял ссылки, но это не имело никакого значения. После этого я попробовал разные варианты платформ в VS2010 и VS2012, но не смог получить удовлетворительный результат. Я приму ДжеремиОтвет, как это было наиболее полезным. Спасибо всем за вашу помощь.