L'esecuzione MSTest ha esito negativo poiché l'assembly di origine non è attendibile

Question

Ho appena aggiunto xUnit al nostro progetto di test (per gli Assert, stiamo ancora usando MSTest come framework) e immediatamente i test eseguiti si sono rifiutati di eseguire uno qualsiasi dei test. Questo è il messaggio di errore:

  

Impossibile eseguire il test in coda '{....}'   Problema di distribuzione dell'esecuzione del test:   posizione del file o della directory   '... xUnit.dll' non è attendibile.

Answer 1

Mi ci sono voluti alcuni tentativi per trovare la risposta su Google, quindi la inserisco qui nel caso in cui qualcun altro incontri lo stesso problema. Una descrizione dettagliata è disponibile all'indirizzo pubblicazione di questo blog .

Fondamentalmente, la correzione invoca facendo clic con il pulsante destro del mouse sul file dll (ad esempio xunit.dll) in Esplora risorse, andando su Proprietà e facendo clic su "Sblocca " nella parte inferiore della scheda accanto al testo "Sicurezza". Sembra che Vista / Windows 2008 contrassegnino automaticamente gli assembly che provengono da altre macchine o Internet come non sicuri.

Come menzionato da un paio di commentatori, potrebbe essere necessario riavviare Visual Studio affinché ciò abbia effetto.

Answer 2

Nel mio team abbiamo avuto lo stesso problema.

La tua soluzione non ha funzionato, ma questo post di Charles Sterling ha fatto aiuto.

Abbiamo usato la seguente riga:

caspol -machine -addgroup 1 -url file://\\server/share/* FullTrust -name DevShare

Answer 3

Dopo aver riscontrato questo problema e bruciato ore cercando di ottenere " Sblocca " per rimanere più a lungo di qualche minuto e / o capire caspol , ho trovato finalmente un po 'di informazioni su Google che gli assiemi saranno bloccati di nuovo la prossima volta che costruirai o ricostruirai il progetto, poiché vengono copiati nuovamente dalla loro posizione di origine originale. (Immagino di non aver mai notato che ciò è accaduto prima con assemblee di riferimenti, ma comunque ...)

La mia correzione per questo era la seguente:

1. Copia tutte le DLL necessarie in un'altra posto per custodia

2. Rimuovi il riferimenti in Visual Studio

3. Elimina fisicamente le DLL nel file cartella bin

4. Sblocca le DLL individualmente nel punto in cui si trovano sono stati copiati

5. Aggiungi i riferimenti di nuovo in Visual Studio dal tenendo il posto

Ogni build o ricostruzione successiva ha funzionato bene in seguito.

Answer 4

In esecuzione su una macchina XP (anche con .NET 3.5 SP1 installato) Non sono riuscito a far funzionare nessuna delle altre soluzioni elencate qui.

Comunque lavorando dallo stesso post di Charles Sterling a cui fa riferimento Davy Landman , Finalmente sono riuscito con questa variazione:

1. Esegui lo strumento di configurazione .NET 2.0 (Impostazioni ... Pannello di controllo ... Strumenti di amministrazione ... Configurazione di .NET Framework 2.0)
2. Fai clic su " Risorse del computer ... Politica di sicurezza runtime ... Macchina ... Gruppi di codici ... All_Code "
3. Crea un nuovo gruppo di codici con condizione di appartenenza di " Zone " = " Intranet locale " e assegnare il set di autorizzazioni " FullTrust "
4. Riavvia Visual Studio

Dopo questi passaggi sono in grado di eseguire test, anche dopo riavvii e ricostruzioni.

MODIFICA: come descritto in questa risposta , tu potrebbe essere necessario installare .NET SDK (che è diverso dal framework .NET) per avere lo strumento di configurazione .NET 2.0 sul tuo sistema.

Answer 5

Ho avuto lo stesso problema con moq. Ma non "sbloccherebbe". Ogni volta che l'ho sbloccato, era ancora bloccato!?!?

Ho dovuto sbloccare il file zip originale che ho scaricato. Quindi copiare nuovamente la DLL dal file zip. Funziona dopo.

Answer 6

Adesso può sembrare davvero ovvio, ma quando stavo facendo clic su sblocca il file era impostato in sola lettura.

Solo dopo aver deselezionato quell'attributo, applicando e selezionando lo sblocco ho effettivamente fatto funzionare questo.

Provaci.

:)

PS: ho anche eliminato tutte le vecchie DLL nella mia cartella bin, solo per assicurarmi che Visual Studio non stesse recuperando quella vecchia.

Answer 7

Ho avuto lo stesso problema con le DLL scaricate bloccate da Vista. È necessario disporre dei diritti di amministratore per ottenere " Unblock " pulsante su Proprietà del file. Ho semplicemente sostituito le DLL con l'ultima versione dal controllo del codice sorgente (TFS) dove le avevo già commesse in precedenza.

Answer 8

• Vai a file
• Fai clic destro e seleziona Properties
• Nel primo registro fare clic su Allow

Answer 9

Ho anche provato ad aprire il file in notepad ++ e a rinominarlo. Approccio leggermente diverso, ma ha funzionato per me. Il file system locale quindi pensa che provenga dalla stessa macchina.

Answer 10

Non è solo il moq.dll che deve essere sbloccato. L'ultimo file zip include un file moq.xml e moq.pdb - facendo riferimento alla dll copia anche questi altri due file nelle cartelle bin. Se tutti e tre non sono stati sbloccati, i test non verranno eseguiti, ho scoperto.