VS2017 n'a pas Pu charger le fichier ou l'assembly Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll ou une de ses dépendances

Lorsque vous essayez d'ouvrir une ancienne solution dans VS2017 il y a un vieux projet de tests Unitaires qui me donne un problème lors de la construction.

Je reçois l'erreur suivante lors de la construction de ce projet de test:

N'a pas pu charger le fichier ou l'assembly 'file:///C:\Projects\MyProj\Test\DAL\UnitTestProj\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll" ou une de ses dépendances. Le système ne peut pas trouver le fichier spécifié.

J'ai vérifié les références du projet et il semble être de référencement Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll. En outre, il n'y a pas d'erreurs de code. Comment pourrais-je jamais si c'est l'un de ses dépendances qu'il ne peut pas trouver?

  • Eh bien, ne C:\Projects\MyProj\Test\DAL\UnitTestProj\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll' existent réellement là? Venez pour penser à elle, pourquoi le diable est-il en premier lieu? Supprimer la référence et l'ajouter en utilisant les Assemblées de l'onglet du gestionnaire de référence. Ne pas parcourir une DLL sur le disque.
  • Je pensais la même chose... est-il en train d'essayer de le trouver dans mon répertoire du projet? J'ai déjà essayé de l'enlever, puis allez à l'gestionnaire de référence > Extensions puis il y a environ 5 doublons de Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll disponible pour référence. Lors du référencement, je reçois le même message d'erreur... ne sais Pas ce que le diable pourrait dire que le projet de regarder dans C:\Projects\MyProj... pour trouver la dll... je ne la vois pas quand je vais Références > Ensembles.. seules les Extensions a elle.
  • Ouais, extensions. Impair. Je vois celui qui travaille avec mes tests est C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll Vous le savez, vous pouvez toujours créer un nouveau projet de test, déplacez vos classes à la main et abandonner le sabotage du fichier de projet...
  • C'est la chose la plus étrange.. Même après re-référencement de l'assemblée par l'intermédiaire de Microsoft Visual Studio 14.0\Common7\IDE\ReferenceAssemblies... Il garde encore erroring en disant que c'est de la chercher dans le répertoire du projet.
  • C'est ce que je pourrais faire, mais ensuite je ne peux pas supporter de traiter avec Contrôle de Source quand il s'agit de choses comme ça.. en Outre, je voudrais le projet de Test à la même vieille version, il a toujours été puisque c'est un projet que je n'ai pas de créer.
  • Une autre alternative est de créer un projet de test, ajoutez les fichiers à la main, mais ajouter des liens (ils existent dans le projet initial), et d'obtenir que le deuxième projet de test de travail. Une fois vérifié qu'il fonctionne très bien, décharger les deux et de comparer les bâclé un avec le travail. Il peut y avoir certains faits à la main deviltries à l'intérieur de la csproj que de bousiller les choses.

InformationsquelleAutor Blake Rivell | 2017-06-13
  1. 37

    J'ai eu un problème similaire (avec le message supplémentaire The "BuildShadowTask" task failed unexpectedly) avec un projet développé à l'origine avec VS2010, et ai passé les dernières heures d'apprentissage sur un autre héritage de la facette du processus de construction.

    Il ya une bonne chance que vous êtes face à accesseur privé fichiers (.accessor), qui ont été déconseillé dans VS2012 (original source 404). Cela a été annoncé dans un annonce de l'équipe de VS2010 qu'ils n'ont plus de travail sur ces fonctions.

    Il ya aussi une chance que vous êtes tout simplement traitant avec erronée refs à la mauvaise version de UnitTestFramework, mais un NuGet restauration doit résoudre ce problème. Si non, voir cette GitHub fil pour un éventuel correctif (modifier manuellement la ref pour le dossier public), ou de passer à la nouvelle MSTest.TestAdapter et MSTest.TestFramework paquets (voir MSDN thread de support).

    Solution

    1. Modifier l'unité de test .csproj et modifier l'élément références de <Shadow Include="Test References\namespace.accessor" /> à <None Include="Test References\namespace.accessor" /> (Shadow => None).
    2. Mieux encore, il suffit de supprimer tous les .accessor des fichiers à partir de l'unité de test du projet Test References dossier.

    Idéalement, vous aussi, vous réécrire vos tests unitaires afin de supprimer les références aux méthodes privées, soit par re-création de l'architecture de séparer les préoccupations ou par la modification des propriétés de internal et à l'aide de "ami" avec la InternalsVisibleToAttribute.

    Pour ceux qui ont besoin de continuer à soutenir les essais de méthodes privées pour une raison quelconque, le même poste offre les suggestions suivantes pour la question logique "What is available for me then?":

    Pour ceux qui souhaitent poursuivre le test interne de l'Api, vous disposez de trois options:

    1. De l'utilisation de Microsoft.VisualStudio.TestTools.UnitTesting.PrivateObject classe pour faciliter l'accès aux internes et privés Api dans votre code. Cela se retrouve dans la Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll de l'assemblée.
    2. Créer un cadre de réflexion qui seraient en mesure de réfléchir à votre code d'accès interne ou privé Api.
    3. Si le code que vous tentez d'accéder est interne, vous pouvez être en mesure d'accéder à votre Api à l'aide de la InternalsVisibleToAttribute de sorte que votre code de test peut avoir accès à l'interne de l'Api.

    Cependant, il n'est pas bon remplacement pour la Génération de Code pour les nouvelles fonctionnalités ajoutées par les lanugage équipes. Vous pouvez créer le TestMethod talons et ensuite supprimer le code interne. Vous avez seulement besoin de garder le talon lui-même.

    Lecture /sources qui m'ont permis de pièce de cet ensemble:

    • Aucune explication pour downvote?
    • J'ai eu ce problème de déplacement de mon projet à un TFS CI de construire. Retrait de "l'Ombre" nœud fixe elle - merci monsieur!
    InformationsquelleAutor brichins
  2. 4

    Cliquez-droit sur le projet de dossier de références. Ajouter la référence > Ensembles > extensions. Vérifiez Microsoft.VisualStudio.QualityTools.UnitTestFramework 10.1, et décochez toutes les anciennes version.

    • Il n'y a pas d'entrée dans les Assemblées > Extensions... (en fait, il n'y a rien)... où avez-vous trouver cette dll? Il ne peut pas être ajouté directement via nuget...
    • Il ne fonctionne pas pour moi.
    • C'est la solution
    • Ajout d'une nouvelle référence, mais j'ai toujours "Le système ne peut pas trouver le fichier spécifié" erreur
    InformationsquelleAutor John H
  3. 0

    Ceci est lié à Visual studio Enterprise 2015, ajouter un nouveau test de charge n'était pas: et spiting comme "Impossible de trouver l'assembly" Microsoft.VisualStudio.QualityTools.LoadTest, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"

    Due à l'Assemblée installé dans les assemblées publiques montre que la version 10.0.0.0 qui est oubliée dans le GAC,

    GAC a seulement 10.1.0.0. Une fois GAC mis à jour avec 10.0.0.0 et redémarrez VS 2015. devrait résoudre le problème semblable à cela.

    Un peu plus en détail pour mieux le raisonnement, l'Assemblage du Système de chemin d'accès et le cheminement d'un projet
    DLL chemin
    ......\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll

    .CSProj version de référence

    • Peut-être que vous pouvez expliquer pourquoi vous pensez que cela résout le problème en question, et de clarifier ce que vous pensez doit être prise. Notez que vous pouvez mettre en forme vos exemples il est donc clair qu'est-ce que l'explication et qu'est ce qu'un chemin d'accès.
    InformationsquelleAutor dhandapani harikrishnan