problemi in esecuzione di unit test in Visual Studio

Question

Quando eseguo la build di rilascio dei miei (VS 2008 NET) test di unità, ottengo la seguente eccezione:

System.IO.FileLoadException: Impossibile caricare il file o assembly 'arcVegaORM, Version = 1.0.3856.24327, Culture = neutral, PublicKeyToken = 0dd85ae1d99ddbee' o una delle sue dipendenze. La definizione manifest di assembly individuato non corrisponde al riferimento all'assembly. (Eccezione da HRESULT: 0x80131040).

Non ottengo l'eccezione quando eseguo i test di compilazione del debug.

L'unità di test framework sta copiando una vecchia versione dell'assieme 'arcVegaORM' nella cartella TestResults \ Out. Non so da dove arrivi la vecchia versione - non corrisponde alla versione nella cartella bin \ Release del progetto.

Sto iniziando a pensare che ci sia un bug con il framework di test dell'unità VS.NET e che abbia la vecchia versione nella cache.

Answer 1

ora ho trovato un post sui forum MSDN - Sembra essere un bug:

http://social.msdn.microsoft.com/Forums/en-US/vststest/thread/af530ba8-1299-4113-a5fe-4f6b009fa599

!! Se spengo la copertura del codice, i test funzionano bene !!

Answer 2

Una cosa da controllare sarebbe GAC (cache di assembly globale). È possibile farlo aprendo Windows Explorer e digitando c: \ windows \ assembly nella barra degli indirizzi (presumendo che il sistema operativo sia installato sul disco c).

Potrebbe richiedere l'assemblaggio dal GAC.

Altre cose da fare sarebbe quella di pulire la soluzione e fare una ricostruzione di tutto per assicurarsi di non avere alcun vecchio riferimento all'assemblaggio.

Inoltre, se si tratta di un'applicazione Web, aiuta sempre a fermare IIS e quindi a pulire la cartella C:\WINDOWS\Microsoft.NET\Framework\framework_version\Temporary ASP.NET Files.

TIP
L'altra cosa da utilizzare è il .Net reflector. Puoi vedere quali dipendenze ha l'assemblaggio e devi assicurarti che siano tutti presenti sulla macchina di destinazione.

Il modo per fare ciò è installare il riflettore, quindi eseguirlo, quindi trascinare il gruppo in esso e vedere le dipendenze dell'assieme. È necessario assicurarsi che ognuna di queste dll di dipendenza sia disponibile sul computer di destinazione e che il numero di versione sia corretto se sono firmati.

TIP2
Si noti che a volte si ottiene problemi in cui l'assembly A è tenuto contro la versione xxx di assemblaggio B, e il gruppo C è destinata contro la versione yyy di montaggio B. In altre parole, 2 gruppi diversi nel progetto sono vincolato a versioni diverse dello stesso assembly. Questa è la versione moderna di Hell DLL. Il modo per aggirare questo è usare il rebinding dell'assemblaggio. Puoi leggere su di esso here.