L'exécution de MSTest échoue parce que l'assemblage source n'est pas fiable.

Question

Je viens d'ajouter xUnit à notre projet de test (pour les assertions, nous utilisons toujours MSTest comme framework) et immédiatement, les exécutions de test ont refusé d'exécuter l'un des tests. Voici le message d'erreur :

Impossible de mettre en file d'attente l'exécution du test "{ .... }' Problème de déploiement de l'exécution du test : L'adresse emplacement du fichier ou du répertoire ...xUnit.dll' n'est pas fiable.

Answer 1

Il m'a fallu plusieurs essais pour trouver la réponse dans Google, je la mets donc ici au cas où quelqu'un d'autre rencontrerait le même problème. Vous trouverez une description détaillée à l'adresse suivante cet article de blog .

En gros, la solution consiste à cliquer avec le bouton droit de la souris sur le fichier dll (xunit.dll par exemple) dans l'Explorateur Windows, à aller dans Propriétés et à cliquer sur "Débloquer" en bas de l'onglet à côté du texte "Sécurité". Il semble que Vista / Windows 2008 marque automatiquement les assemblages provenant d'autres machines ou d'Internet comme non sécurisés.

Comme l'ont mentionné quelques commentateurs, il se peut que vous deviez également redémarrer Visual Studio pour que cela prenne effet.

Answer 2

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

Votre solution n'a pas fonctionné, mais ce message par 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 rencontré ce problème et passé des heures à essayer de faire en sorte que "Débloquer" tienne plus de quelques minutes et/ou à trouver le moyen de caspol en vain, j'ai finalement trouvé un petit truc via Google qui dit que les assemblages seront à nouveau bloqués la prochaine fois que vous construisez ou reconstruisez le projet, puisqu'ils sont recopiés depuis leur emplacement source original. (Je suppose que je n'ai jamais remarqué que cela se produisait auparavant avec les assemblages de références, mais bon...)

J'ai résolu ce problème de la manière suivante :

1. Copiez toutes les DLLs nécessaires dans un autre endroit pour les conserver

2. Supprimer les dans Visual Studio

3. Supprimez physiquement les DLL dans le dossier dossier bin

4. Débloquez les DLL individuellement à l'endroit où elles ont été copiées

5. Ajoutez les références dans Visual Studio à partir de l'emplacement point d'attente

Toutes les constructions ou reconstructions suivantes ont fonctionné sans problème par la suite.

Answer 4

Sur une machine XP (même avec .NET 3.5 SP1 installé), je n'ai pu faire fonctionner aucune des autres solutions énumérées ici.

Cependant, en travaillant à partir du même post par Charles Sterling que les références de Davy Landman, j'ai finalement réussi avec cette variation :

1. Exécutez l'outil de configuration de .NET 2.0 (Paramètres.... Panneau de configuration... Outils d'administration... .NET Framework 2.0 Configuration)
2. Cliquez vers le bas sur "Poste de travail ... Politique de sécurité de l'exécution ... Machine ... Groupes de codes ... Tous les codes".
3. Créez un nouveau groupe de code avec la condition d'appartenance "Zone"="Intranet local" et attribuez le jeu de permissions "FullTrust".
4. Redémarrer 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 cette réponse Si vous avez besoin de l'outil de configuration .NET 2.0, il se peut que vous deviez installer le SDK .NET (qui est différent du cadre .NET) afin de l'avoir sur votre système.

Answer 5

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

J'ai dû débloquer le fichier zip original que j'ai téléchargé. Puis recopier la DLL du fichier zip. Ça a marché après ça.