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

StackOverflow https://stackoverflow.com/questions/201327

  •  03-07-2019
  •  | 
  •  

Question

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

  

Échec de la mise en file d'attente du test '{....}'   Problème de déploiement du test: Le   emplacement du fichier ou du répertoire   '... xUnit.dll' n'est pas fiable.

Était-ce utile?

La solution

Il m'a fallu plusieurs essais pour trouver la réponse dans Google. Je la mets ici au cas où quelqu'un d'autre rencontrerait le même problème. Une description détaillée est disponible à la cette publication .

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

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

Autres conseils

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

Votre solution n'a pas fonctionné, mais cette publication de Charles Sterling l'a été aide.

Nous avons utilisé la ligne suivante: 

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

Après avoir eu ce problème et passé de nombreuses heures à essayer d'obtenir "Débloquer". Pour rester plus que quelques minutes et / ou trouver caspol en vain, j'ai finalement trouvé un petit détail sur Google indiquant que les assemblys seront de nouveau bloqués la prochaine fois que vous construirez ou reconstruirez le projet, car ils sont recopiés à partir de leur emplacement source d'origine. (Je suppose que je n'ai jamais remarqué que cela se soit produit auparavant avec des assemblages de références, mais enfin ...)

Mon correctif est le suivant:

  1. Copiez toutes les DLL nécessaires sur un autre point de garde

  2. Retirez le références dans Visual Studio

  3. Supprimez physiquement les DLL du dossier bin

  4. Débloquer les DLL individuellement à l'endroit où ils ont été copiés

  5. Ajouter les références retour dans Visual Studio à partir du point d'attente

Chaque construction ou reconstruction ultérieure a bien fonctionné par la suite.

Fonctionnant sur une machine XP (même avec .NET 3.5 SP1 installé), aucune des solutions répertoriées ici ne fonctionnait.

Cependant, travaillant à partir du même post par Charles Sterling que Davy Landman référence , J’ai enfin réussi avec cette variante:

  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 vers le bas pour "Poste de travail ... Politique de sécurité d'exécution ... Machine ... Groupes de codes ... Tous_Code"
  3. Créez un nouveau groupe de codes 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 peux exécuter des tests, y compris après des redémarrages et des reconstructions.

EDIT: comme décrit dans la cette réponse , vous Vous devrez peut-être installer le Kit de développement .NET (qui est différent du .NET Framework) pour pouvoir disposer de l’outil de configuration .NET 2.0 sur votre système.

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

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

Cela peut sembler très évident maintenant, mais lorsque je cliquais sur le déblocage, le fichier était défini en lecture seule.

Seulement après avoir désélectionné cet attribut, après application, puis en sélectionnant débloquer, cela a fonctionné.

Essayez-le.

:

PS: j'ai également supprimé toutes les anciennes dll de mon dossier bin, juste pour m'assurer que Visual Studio ne récupérait pas l'ancien.

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

  • Accédez au fichier
  • Faites un clic droit et sélectionnez Propriétés
  • Sur le premier registre, cliquez sur Autoriser

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

Ce n'est pas seulement le fichier moq.dll qui doit être débloqué. Le dernier fichier zip inclut les fichiers moq.xml et moq.pdb - le référencement de la dll copie également ces deux autres fichiers dans les dossiers bin. Si les trois n’ont pas été débloqués, les tests ne fonctionneront pas, j’ai trouvé.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top