2010-10-21 25 views
12

Ho riscontrato un problema che ha ricevuto molta attenzione che, nonostante sia molto googlante, non ho potuto risolvere. Ho un progetto di prova allegato alla mia applicazione MVC 2 di Visual Studio 2010. Quando provo a eseguire i miei test, ottengo:Visual Studio 2010 - non sono stati eseguiti test perché non sono stati caricati test o i test selezionati sono stati disabilitati.

"non sono stati eseguiti test perché non sono stati caricati test o i test selezionati sono disabilitati."

A seguito di questo, ho seguito le istruzioni riportate in questi posti, senza alcun risultato:

Inoltre, i rapporti console di output :

File "Impossibile caricare file o assembly": // \ shared \ shared \ IT \ Development \ TPS \ TPS.Tests \ bin \ Debug \ TPS.Tests.dll "o una delle sue dipendenze. non supportato. (Eccezione da HRESULT: 0x80131515) "

Ho confermato che le impostazioni di generazione del progetto di test sono le stesse del progetto principale (qualsiasi CPU interessata).

Pertanto, è un problema accedere alla risorsa tramite la condivisione di rete? Altrimenti, qualcuno ha un suggerimento?

+0

Stai dicendo che avete il vostro codice sorgente in una condivisione? –

+0

Sì, ho il progetto su una quota – Hanshan

risposta

7

Avere il codice sorgente su una condivisione è semplicemente sbagliato (punto) e porterà a tutti i tipi di 'gremlins'.

Fatevi un favore, utilizzate il controllo del codice sorgente e una copia locale del codice sorgente. Perderai molto meno tempo e, come bonus, sarai in grado di monitorare chi ha cambiato cosa.

Se si utilizza TFS, lo Visual Studio TFS Branching Guide 2010 è una risorsa preziosa.

Se si utilizza SubVersion, lo Red Bean Book è eccellente.

+0

ok, lo controllerò fuori – Hanshan

+0

Non basta controllare, fallo! ;) –

+1

Haha: tutto bene. Funziona bene ora. Grazie mille per il tuo aiuto, amico! – Hanshan

10

Se si desidera continuare a utilizzare una condivisione di rete per ospitare gli assembly in .NET 4, è possibile modificare un'opzione di configurazione di Visual Studio per garantire la piena affidabilità di tali assembly. E 'necessario modificare C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe.config e aggiungere la seguente riga:

<loadFromRemoteSources enabled="true"/> 

Per l'elemento configuration/runtime. Questo è descritto in (leggermente) più in dettaglio allo http://msdn.microsoft.com/en-us/library/dd409252%28VS.100%29.aspx. Non consiglierei di apportare questo cambiamento senza comprendere le implicazioni sulla sicurezza di farlo, alcune delle quali sono delineate in quell'articolo di MSDN.

In generale, tuttavia, sono d'accordo con la risposta precedente. Ospitare progetti di Visual Studio su una condivisione di rete creerà un gran numero di problemi con pochissimi benefici.

+0

Aaargh. Grazie. – aronp

+0

Ottima risposta, mi ha salvato un sacco di dolore. – Jay13

1

Ero in esecuzione tutto locale ma ho ancora avuto il problema. Ho scoperto che ciò che ha causato la rimozione di un tag xml durante la modifica manuale.

aggiuntivo:

CodedUITest() tra parentesi tag

sulla riga immediatamente sopra la classe in cui tutti i vostri metodi di prova sono.

aggiuntivo:

TestMethod() tra parentesi tag

sulla linea immediatamente sopra i vostri metodi di prova che si desidera eseguire.

costruire progetto ed eseguire.

0

ho lottato con questo per giorni, e non ha trovato la risposta (per la mia situazione) da nessuna parte, così anche se mi piacerebbe butto giù la mia esperienza ...

così ho avuto lo stesso problema, facendo quello che Ho pensato di provare localmente su un progetto di test creato localmente .. (Sono un novizio ...) ma restituisco lo stesso errore menzionato sopra:/

In ogni caso sembra che VS2010 abbia inserito di default il mio progetto dir all'interno del cartella della libreria, che è stata classificata come rete, successivamente tutti i file all'interno erano "non disponibili offline".

Spostando la mia dir di progetto in c: // i miei file di progetto sono diventati indicizzabili. (Con mia grande sollievo!)

1

Ho provato le seguenti operazioni mentre si verifichi questo problema e per fortuna il problema ottenuto risolto ...

  1. chiudere la soluzione e aprire il vuoto VS editore e estrarre il file testrunconfig
  2. Aprire la soluzione e nella colonna CodeCOverage, deselezionare e controllare la DLL disponibile (queste dll avrebbero un simbolo di avviso)
  3. Ricostruire la soluzione e ora eseguire i test case.

Spero che questo risolve il problema ... :)

Problemi correlati