Échec du chargement de NUnit DLL
Le message d'erreur suivant s'affiche lorsque j'essaie d'exécuter des tests unitaires dans Visual Studio:
NUnit failed to load w:\Repos\trading.tools\Trading.Tools.Test\bin\x64\Debug\Trading.Tools.Test.dll
J'utilise
- Visual Studio Community 2013
- NUnit Adapter 3.4.0.0
- NUnit 3.4.1
Ce qui est étrange, c’est que j’ai un autre projet qui est mis en place de la même manière que celui-ci et qui fonctionne très bien.
J'ai également téléchargé NUnit 3.4.1 et l'ai installé. Quand je cours
nunit3-console.exe Trading.Tools.Test.dll
tout fonctionne très bien ... Des idées sur ce que je peux faire?
Merci beaucoup Konstantin
Modifier # 1
Voici la sortie complète de la console de Visual Studio lorsque vous essayez d'exécuter tous les tests.
Test run will use DLL(s) built for framework Framework45 and platform X86. Following DLL(s) will not be part of run:
Trading.Tools.Test.dll, Trading.Tools.dll are built for Framework Framework45 and Platform X64.
Go to http://go.Microsoft.com/fwlink/?LinkID=236877&clcid=0x409 for more details on managing these settings.
NUnit Adapter 3.4.0.0: Test discovery starting
NUnit failed to load w:\Repos\trading.tools\Trading.Tools.Test\bin\x64\Debug\Trading.Tools.Test.dll
Assembly contains no NUnit 3.0 tests: w:\Repos\trading.tools\Trading.Tools\bin\x64\Debug\Trading.Tools.dll
NUnit Adapter 3.4.0.0: Test discovery complete
Comme vous pouvez le constater, il est très évident que NUnit attend une construction x86, mais je construis pour une plate-forme x64. Et encore une fois, ma construction x64 fonctionne très bien si je l’exécute en utilisant nunit3-console.exe.
Voici ce que je vois dans le fichier csproj:
<Reference Include="nunit.framework, Version=2.6.4.14350, Culture=neutral, PublicKeyToken=96d09a1eb7f44a77, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<HintPath>..\packages\NUnit.3.4.1\lib\net45\nunit.framework.dll</HintPath>
</Reference>
La chose étrange ici est qu'il spécifie en utilisant Version=2.6.4.14350 mais en référençant une dll 3.4.1.
La prochaine question à ce stade est donc: comment puis-je faire en sorte que NUnit exécute ma compilation x64? Des idées?
J'ai eu un problème similaire, la clé est le fait que c'est le Test Runner dans Visual Studio qui indique que seuls les assemblys x86 seront testés. Je suppose à partir de cela qu'il force alors l'utilisation du coureur x86 NUnit. Pour changer cela (au moins dans VS2015 et VS2017), accédez à Test> Test Settings> Default Processor Architecture> X64.
Vous pouvez également définir la cible d'exécution dans le fichier runsettings. Vous devez ensuite sélectionner ce fichier. Cela devrait rendre la solution plus stable . Un fichier runsettings qui ne le définit que peut ressembler à:
Pour l'activer, procédez comme indiqué dans la figure ci-dessous:
Lorsque vous le sélectionnez dans le menu de test (1), il sera ajouté en tant que celui sélectionné dans le menu (2), puis une reconstruction fera apparaître le test dans l'explorateur de tests (3).
L’utilisation d’un fichier runsettings offre un bonus supplémentaire, c’est-à-dire qu’il fonctionnera ensuite correctement sur le système TFS Build, si vous l’utilisez. J'ai écrit un article de blog sur cette question, voir http://hermit.no/how-to-control-the-selection-of-test-runner-in-tfsvsts-making-it-work-with-x86x64 -selected-cibles/
Après avoir essayé sans succès toutes les autres réponses ci-dessus, voici ce qui a fonctionné pour moi:
Dans mon cas, le projet et la solution .NET se trouvent sur un lecteur monté (j'utilise un développement MacBook et Parallels for .NET). Le montage contient également les emplacements/bin/debug et/bin/release où NUnit a tenté de lire le "test" DLL.
Le correctif consistait à déplacer les fichiers de solution/projet sur le lecteur C: de mon image Windows. Les tests ont été découverts immédiatement.
Apparemment, l'emplacement partagé/monté n'était pas à son goût. Je ne sais pas pourquoi, car le montage est permanent et en lecture/écriture pour tous les utilisateurs de l'image Windows. Je soupçonne des problèmes d'autorisations de fichier ou peut-être que le montage entier n'est pas accessible à l'utilisateur/processus exécutant la logique de découverte NUnit.
Je ne pouvais pas exécuter mes tests et j'ai trouvé que c'était l'un des problèmes. Il se trouve que mon TestFixture étaitinternal. Il suffit de passer àpublicpour résoudre mon cas.
J'ai eu cette erreur lors de l'écriture de la méthode de test unitaire. Et remarqué la cause fondamentale de l’un des dll dépendants manquant à charger. Cette erreur ("NUnit n'a pas pu charger le fichier .dll") s'est affichée dans la fenêtre Sortie ("Test") après avoir modifié le code de la méthode de test et tenté de l'exécuter. Après la mise à jour du paquet nuget pour la dll dépendante, nunit a commencé à sélectionner la dll du projet test et les scénarios de test ont été exécutés.