Mam projekt biblioteki .NET z około 500 testami jednostkowymi. Wszystkie te testy działają poprawnie w Visual Studio 2012. Jednak niektóre z moich testów nie działają w Visual Studio 2010. W tych nieudanych testach używamMoq aby wyszydzić kilka typów InteropMicrosoft.Office.Interop.Excel. Test kończy się niepowodzeniem przy próbie uzyskania dostępu do tych wyszydzonych typów interop:

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

Wyjątek ten oznacza, że ​​zapomniałem ustawić odpowiedni getter właściwości na moim makiecie. Co nie jest prawdą:

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

Teraz mogę sobie wyobrazić, że Moq może nie działać zbyt dobrze z Interop Types. Najbardziej jednak zastanawia mnie to, że testy te działają poprawnie w Visual Studio 2012, ale nie działają w Visual Studio 2010.

Dlaczego moje Visual Studio wpływa na zachowanie mojego kodu?

AKTUALIZACJA: 3-11-2012

Ok, więc zrozumiałem:

Mam dwa projekty; Core i Core.UnitTest. Core jest rzeczywistą biblioteką, podczas gdy Core.UnitTest jest projektem testowym jednostki biblioteki Core.Oba projekty odwołują się do Microsoft.Office.Interop.Excel z włączonymi Embed Interop Types.Ponieważ EIT jest włączony, oba projekty zawierają własny „widok” biblioteki Microsoft.Office.Interop.Excel. Widok zawiera wszystkie klasy, metody i właściwości używane w ich odpowiednich projektach.Ponieważ oba projekty używają różnych klas, metod i właściwości Microsoft.Office.Interop.Excel, wbudowane typy obu bibliotek różnią się. Na przykład. ListRow w Core ma właściwość Index i Range, podczas gdy ListRow w Core.UnitTest ma tylko właściwość Range.Chociaż oba typy są różne i nie mają wspólnego interfejsu ani super klasy, sąodpowiednik. Oznacza to, że CLR traktuje je tak, jakby były takie same, i pozwoli ci używać tych typów w granicach zespołu. Na przykład. instancja ListRow z Core.UnitTest będzie działać poprawnie po przekazaniu do metody w bibliotece Core. Właściwość Shared Range będzie działać, podczas gdy brakująca właściwość Index wyśle ​​wyjątek MissingMethodException podczas dostępu.Wspomniane zachowanie działa nawet w przypadku wyśmiewanych typów. Wyśmiewany obiekt Mocka [Excel.ListRow] będzie działał dobrze podczas przekraczania granicy zespołu.Niestety zachowanie opisane w poprzednim punkcie działa tylko wtedy, gdy kompiluję moje zestawy w Visual Studio2012. Kiedy buduję moje zestawy w Visual Studio2010 i debuguj mój kod, widzę, że wyśmiewana instancja ListRow jest przekazywana do metody mojego projektu Core. W momencie, gdy instancja przekracza granicę zespołu, wszystkie metody i właściwości ListRow tracą implementację i rzucają MissingMethodExceptions.Teraz, dla zabawy, udało mi się złagodzić ten problem, upewniając się, że oba osadzone typy ListRow są wyrównane. Na przykład. aby kompilator mógł stworzyć ten sam widok ListRow w obu projektach, upewniłem się, że użyłem dokładnie tych samych metod i właściwości w moim projekcie UnitTest. Oznacza to dodanie fałszywych linii, takich jak: var dummy = listRow.Index. Gdy kompilator utworzył identyczne widoki mojego osadzonego typu ListRow, instancja mogła przekraczać granice składania bez utraty implementacji.

Pozostaje jednak pytanie: Co powoduje tę różnicę w zachowaniu między Visual Studio 2010 i Visual Studio 2012?

AKTUALIZACJA: 9-11-2012

Rozwiązanie demonstracyjne: http://temp-share.com/show/KdPf6066h

Stworzyłem małe rozwiązanie, aby pokazać efekt. Rozwiązanie składa się z biblioteki i projektu UnitTest. Oba odwołują się do Microsoft.Office.Interop.Excel.Range z włączonym EIT. Test działa dobrze w VS2012, ale zgłasza MissingMethodException w VS2010. Odkomentowanie fałszywej linii w teście sprawi, że będzie działać w VS2010.

KOŃCOWA AKTUALIZACJA: 29-12-2012

Przepraszam za późną aktualizację. Mój kolega znalazł rozwiązanie, ale nie mogłem go odtworzyć na moim komputerze. W międzyczasie nasza firma przełączyła się na TFS2012, więc nie jest to już dla mnie problem blokujący. Dwa najważniejsze wnioski, które mój kolega przedstawił, to:

Semantyka platformy „Any CPU” zmieniła się z Visual Studio 2010 na Visual Studio 2012. Spowoduje to wygenerowanie różnych plików .DLL w zależności od tego, czy używasz VS2010, czy VS2012.Oba projekty odnosiły się do różnych wersji Microsoft.Office.Interop.Excel.

Sprawdziłem swoje projekty i poprawiłem referencje, ale to nie miało znaczenia. Następnie wypróbowałem różne odmiany platform zarówno w VS2010, jak i VS2012, ale nie udało mi się uzyskać zadowalającego wyniku. Przyjmę odpowiedź Jeremy'ego, ponieważ była najbardziej pomocna. Dziękuję wszystkim za pomoc.