2013-09-04 10 views
7

Dostaję dziwne, cóż, nie będę nawet nazywał tego "błędem" per se. Po prostu za każdym razem, gdy mówię programowi Visual Studio 2012 o "uruchomieniu wszystkich" moich testów jednostkowych (przy użyciu testu MS), otrzymuję ten dziwny komunikat w oknie wyjściowym:Wystąpił wyjątek podczas wywoływania executora "executor: // mstestadapter/v1": Typ nie został rozwiązany dla członka

Wystąpił wyjątek podczas wywoływania executora: executor: // mstestadapter/v1 ': Typ nie został rozwiązany dla podzespołu "ZESTAW"

Rzecz w tym: ten błąd pojawia się tylko podczas uruchamiania testów jednostkowych i nie jest to "wyjątek", tylko że testy nie działają, nigdy nawet nie zaczynaj. Program działa poprawnie po wdrożeniu w usługach IIS i mogę ręcznie debugować test jednostki i przejść przez nią, i działa dobrze, więc nie mogłem uzyskać żadnych szczegółowych informacji.

Wygląda na to, że mój zespół, który jest zespołem osób trzecich, nie został znaleziony podczas mojego testu podczas wykonywania testów. Ilekroć ładuję te zespoły w GAC, to działa dobrze.

Czy ktoś ma pojęcie, co może być przyczyną tego problemu i co mogę zrobić, aby go rozwiązać, aby moje testy jednostek działały bez tego "błędu"?

To jest usługa sieciowa WCF łącząca się z zewnętrzną bazą danych za pośrednictwem własnej odsłoniętej usługi WWW, która jest tym, co są zgromadzeniami innych firm.

EDIT:

Według dzienników fuzyjnych, biegacz testów jednostkowych (VSTestConfig) szuka tych konkretnych zespołów w swoim folderze wykonywalnego, a nie w folderze bin \ Debug, jak bym się spodziewał. Czy ktoś inny widział ten problem, gdzie, mimo że złoenia są obecne w bin \ debug, to nie "szuka" ich tam?

Edit 2:

Rok później ... Środowisko Pracowałem z kiedy mam ten błąd jest dawno już minęły. Naprawdę nie pamiętam nawet, jak skonfigurowano środowisko. Jestem prawie pewien, że miało to jakiś związek ze sposobem, w jaki miałem instalację Visual Studio lub z moim GAC ... kto wie. Wątpię, by na to pytanie odpowiedziano w jakimkolwiek stopniu, ale pod każdym względem, jeśli ktoś kiedykolwiek dostanie ten błąd i wymyśli go, daj nam znać! :)

+0

Próbowano dodać ścieżkę do zespołu zewnętrznego jako [ścieżka referencyjna] (http: //www.codeproject.com/Articles/184718/Take-advantage-of-Reference-Paths-in-Visual-Studio)? VS prawdopodobnie nie pobiera automatycznie pliku z folderu bin (może skopiuj lokalnie jest false?). – Will

+0

Tak, próbowałem obu. Skopiuj lokalne jest prawdziwe i próbowałem ścieżki referencyjnej. Ani działa. –

+0

Otrzymuję ten sam problem. Działa, gdy uruchamiam unittest w trybie debugowania, ale normalne uruchamianie kończy się niepowodzeniem z tym komunikatem o błędzie. Czy zrobiłeś jakieś postępy w tej sprawie? – rudimenter

Odpowiedz

4

W moim przypadku było to odniesienie zerowe za kulisami.

Powinieneś sprawdzić, gdzie typ jest używany, gdy narzeka. Jeśli go znaleźć można debugować go wstawiając poniższy wiersz kodu użytkownika:

Debugger.Attach(); 
Debugger.Break(); 

Aby to naprawić, można zrobić lepszą konfigurację testową lub skorzystać z następującą linię pominąć kod generujący błąd.

var processName = Process.GetCurrentProcess().ProcessName; 
if(processName == "vstest.executionengine.x86"){ /*Do something else*/ } 

Co ja również podejrzewany jest [assembly: AssemblyCulture("")] ponieważ test, który udało zależy od kultury i jestem zakładając zawodnik testowy działa bez kultury.

0

Znalazłem dla mnie to wyjątek ObjectDisposedException. Użyłem Debugger.Launch() do podłączenia debuggera we właściwym czasie.

Powiązane problemy