L'exécution de MSTest échoue parce que l'assembly source n'est pas approuvé

Question

J'ai simplement ajouté xUnit à notre projet de test (pour les Asserts, nous utilisons toujours MSTest comme framework) et immédiatement les tests ont refusé d'exécuter l'un des tests. Tel est le message d'erreur:

Échec de la file d'attente test de fonctionnement '{....}' problème de déploiement de l'exécution du test: L'emplacement du fichier ou du répertoire '... xUnit.dll' est pas de confiance.

Answer 1

Il m'a fallu quelques tentatives pour trouver la réponse dans Google, donc je la mets ici au cas où quelqu'un d'autre se heurterait au même problème. Une description détaillée peut être trouvée au this blog posting. Fondamentalement, le correctif invovles droit sur le fichier dll (xunit.dll par exemple) dans l'Explorateur Windows, aller à Propriétés, et en cliquant sur "Débloquer" au bas de l'onglet à côté du texte de «sécurité». Il semble que Vista/Windows 2008 marquera automatiquement les assemblages provenant d'autres machines ou d'Internet comme dangereux.

Comme certains commentateurs l'ont mentionné, vous devrez peut-être redémarrer Visual Studio pour que cela prenne effet.

Answer 2

Dans mon équipe, nous avions le même problème.

Votre solution n'a pas fonctionné, mais this post by Charles Sterling a aidé.

Nous avons utilisé la ligne suivante:

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

Answer 3

Après avoir cette question et les heures de combustion essayant d'obtenir « Débloquer » pour coller plus longtemps que quelques minutes et/ou de déterminer caspol en vain, je Finalement, nous avons trouvé une petite friandise via Google que les assemblages seront à nouveau bloqués la prochaine fois que vous construisez ou reconstruisez le projet, car ils sont recopiés à partir de leur emplacement source d'origine. (Je suppose que je ne remarqué que cela se passait avant avec les assemblées de références, mais quand même ...)

Mon correctif pour ce sont les suivantes:

1. Copiez tous les DLL nécessaires à un autre endroit sûr pour

liées à cette conservation

2. Retirez les références dans Visual studio

3. supprimer physiquement les DLL dans le dossier bin

4. Déboucher les DLLs individuellement dans l'endroit où ils ont été copiés de

5. Ajoutez les références retour dans Visual Studio de l'endroit tenant

Chaque construction ultérieure ou la reconstruction travaillé bien après.

Answer 4

J'ai eu le même problème avec les DLL téléchargées bloquées par Vista. Vous avez besoin des droits d'administrateur pour obtenir le bouton "Débloquer" sur les propriétés du fichier. I simplement remplacé les DLL avec la dernière version du contrôle de source (TFS) où je les avais engagés auparavant.

Answer 5

En cours d'exécution sur une machine XP (même avec .NET 3.5 SP1 installé), je n'ai pas réussi à faire fonctionner les autres solutions listées ici.

travail Cependant de la même post by Charles Sterling que les références Davy Landman, je réussis enfin avec cette variation:

1. exécuter l'outil de configuration .NET 2.0 (Paramètres ... Panneau de configuration ... Outils d'administration ... Configuration de .NET Framework 2.0)
2. Cliquez sur "Poste de travail ... Stratégie de sécurité d'exécution ... Machine ... Groupes de codes ... Code_Code"
3. Créer un nouveau groupe de code avec la condition d'appartenance "Zone" = "Intranet local" et attribuer le jeu d'autorisations "FullTrust"
4. Redémarrez Visual Studio

Après ces étapes, je suis en mesure d'exécuter des tests, y compris après des redémarrages et des reconstructions.

EDIT: comme décrit dans this answer, vous devrez peut-être installer le SDK .NET (qui est différent du framework .NET) afin de disposer de l'outil de configuration .NET 2.0 sur votre système.

Answer 6

J'ai eu le même problème avec moq. Mais ne "débloquerait" pas. Chaque fois que je le débloquais, il était toujours bloqué!?!?

J'ai dû débloquer le fichier zip d'origine que j'avais téléchargé. Ensuite, copiez à nouveau la DLL à partir du fichier zip. Ça marche après ça.

Answer 7

J'ai également essayé d'ouvrir le fichier dans le bloc-notes ++ et de le renommer. Approche légèrement différente, mais cela a fonctionné pour moi. Le système de fichiers local pense alors qu'il provient de la même machine.

Answer 8

Cela peut sembler vraiment évident maintenant, mais lorsque je cliquais sur débloquer le fichier était en lecture seule.

Ce n'est qu'après avoir décoché cet attribut, appliqué, puis sélectionné le déblocage que j'ai réussi à le faire fonctionner.

Essayez-le.

:)

PS: Je également supprimé tous les anciens dll dans mon dossier bin, juste pour vous assurer que Visual Studio ne captait pas l'ancien.

Answer 9

Ce n'est pas seulement le moq.dll qui doit être débloqué. Le fichier zip le plus récent comprend un fichier moq.xml et un fichier moq.pdb - en faisant référence à la DLL, ces deux autres fichiers sont également copiés dans les dossiers de la corbeille. Si les trois n'ont pas été débloqués, les tests ne seront pas exécutés, j'ai trouvé.

Answer 10

• Aller à file
• Faites un clic droit et sélectionnez Properties
• Sur le premier registre cliquer sur Allow