web-dev-qa-db-fra.com

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

Lorsque vous essayez d'ouvrir une ancienne solution dans VS2017, un ancien projet de test unitaire me pose un problème lors de la construction.

Je continue à avoir l'erreur suivante lors de la construction de ce projet de test:

Impossible de charger le fichier ou le fichier Assembly: /// C:\Projects\MyProj\Test\DAL\UnitTestProj\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll 'ou l'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 faire référence à Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll. De plus, il n'y a pas d'erreur de code. Comment pourrais-je jamais savoir s'il s'agit d'une de ses dépendances qu'il ne peut pas trouver?

asp.net.netvisual-studiovisual-studio-2017vs-unit-testing-framework
13
Blake Rivell

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 j'ai passé les dernières heures à apprendre un autre aspect hérité du processus de construction.

Il y a de fortes chances pour que vous traitiez avec des fichiers d'accès privés (.accessor), qui étaient obsolètes dans VS2012 ( source d'origine est 404). Cela a été annoncé dans une annonce de l'équipe VS2010 qu'ils ne travaillaient plus sur ces fonctionnalités.

Il est également possible que vous traitiez uniquement avec des références erronées à la mauvaise version de UnitTestFramework, mais une restauration de NuGet devrait résoudre ce problème. Si ce n'est pas le cas, consultez ce fil GitHub pour un correctif éventuel (remplacez manuellement le fichier ref par le dossier public) ou déplacez-le vers les nouveaux packages MSTest.TestAdapter et MSTest.TestFramework (voir Fil de support MSDN ).

Solution

  1. Editez le test unitaire .csproj et modifiez les références d’article de <Shadow Include="Test References\namespace.accessor" /> à <None Include="Test References\namespace.accessor" /> (Shadow => None).
  2. Mieux encore, supprimez simplement tous les fichiers .accessor du dossier Test References du projet de test unitaire.

Dans l'idéal, vous devriez également réécrire vos tests unitaires pour supprimer les références aux méthodes privées, soit en restructurant l'architecture pour séparer les problèmes, soit en modifiant les propriétés en internal et en utilisant "ami" avec le InternalsVisibleToAttribute .

Pour ceux qui doivent continuer à prendre en charge le test des méthodes privées pour une raison quelconque, le même message fournit les suggestions suivantes à la question logique "What is available for me then?":

Pour ceux qui souhaitent continuer à tester les API internes, vous avez trois options: 

  1. Utilisez la classe Microsoft.VisualStudio.TestTools.UnitTesting.PrivateObject pour vous aider à accéder aux API internes et privées de votre code. Cela se trouve dans l'assembly Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll. 
  2. Créez un cadre de réflexion capable de refléter votre code pour accéder aux API internes ou privées. 
  3. Si le code auquel vous essayez d'accéder est interne, vous pourrez peut-être accéder à vos API à l'aide de InternalsVisibleToAttribute afin que votre code de test puisse accéder aux API internes. 

Cependant, il n'y a pas de bon remplacement pour la génération de code pour les nouvelles fonctionnalités ajoutées par les équipes de lanugage. Vous pouvez créer les stubs TestMethod puis supprimer le code interne. Il vous suffit de garder le talon lui-même.

Lectures complémentaires/sources qui m'ont aidé à comprendre cela:

28
brichins

Cliquez avec le bouton droit sur le dossier de références du projet. Ajouter une référence> Assemblées> extensions. Vérifiez Microsoft.VisualStudio.QualityTools.UnitTestFramework 10.1 et décochez toute version antérieure.

2
John H

Ceci est lié à Visual studio Enterprise 2015, l'ajout d'un nouveau test de charge échouait et la création de "Impossible de trouver l'assembly" Microsoft.VisualStudio.QualityTools.LoadTest, version = 14.0.0.0, Culture = neutre, PublicKeyToken = b03f5f7f11d50a3a "

En raison de l’assemblage installé dans les assemblées publiques, la version 10.0.0.0 est manquante dans GAC,

GAC n'avait que 10.1.0.0. Une fois que GAC mis à jour avec 10.0.0.0 et redémarrez VS 2015. devrait résoudre le problème similaire à celui-ci.

Quelques détails supplémentaires pour un meilleur raisonnement, chemin d'assemblage système et chemin de projet Chemin de DLL ......\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.QualityTools .UnitTestFramework.dll

.CSProj version de référence

0
dhandapani harikrishnan