Référence Microsoft.VisualStudio.QualityTools.UnitTestFramework pour la génération CI
J'ai créé un projet de test C # dans VS2015 RC. il construit localement mais quand j'essaye de construire sur notre serveur de construction CI (TeamCity) il échoue avec des erreurs:
UnitTest1.cs (2,17): erreur CS0234: le nom de type ou d'espace de noms 'VisualStudio' n'existe pas dans l'espace de noms 'Microsoft' (vous manque une référence d'assembly?) [... .Tests.csproj] UnitTest1.cs (9,10): erreur CS0246: le type ou le nom de l'espace de noms 'TestMethod' est introuvable (manque-t-il une directive using ou une référence d'assembly?) [... .Tests.csproj]
C'est clairement parce que l'assembly contenant ces espaces de noms (Microsoft.VisualStudio.QualityTools.UnitTestFramework) N'est pas sur le serveur de build; sur ma machine locale, il réside dans C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll.
Je pourrais copier l'assembly dans ma solution afin qu'il devienne une partie de la base de code, mais le déplacement manuel des fichiers semble un peu un hack inélégant. J'ai cherché autour de nuget et j'ai trouvé http://www.nuget.org/packages/Microsoft.VisualStudio.QualityTools.UnitTestFramework/ dont je pensais qu'il ferait l'affaire, mais l'installation de ce package a échoué avec:
Install-Package: impossible d'installer le package "Microsoft.VisualStudio.QualityTools.UnitTestFramework 11.0.50727.1". Vous essayez d'installer ce package dans un projet qui cible ".NETFramework, Version = v4.5.2", mais le package ne contient aucune référence d'assembly ni fichier de contenu compatible avec ce framework.
Quelle est ma meilleure option pour résoudre ce problème? Je suis surpris que la création d'un projet de test dans VS2015 n'inclue pas automatiquement toutes les dépendances dont j'ai besoin, bien que je sois peut-être naïf (je suis une sorte de netter dot naissant).
La réponse est similaire à l'option 1 dans réponse de eng.augusto .
Microsoft ne fournit pas NuGet pour la dernière version de Microsoft.VisualStudio.QualityTools.UnitTestFramework, mais le fournit dans le cadre de Visual Studio ( normalement à C:\Program Files (x86 )\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll)
J'ai créé le dossier Microsoft.VisualStudio.QualityTools en tant que sous-dossier de ma solution et copié
Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll Microsoft.VisualStudio.QualityTools.UnitTestFramework.xml
Les fichiers doivent être ajoutés au contrôle de code source (même si les DLL sont généralement ignorées).
J'ai ensuite modifié les références dans mon Test.csproj pour faire référence à un nouvel emplacement.
Hmm j'ai quelques idées, alors choisissez celle qui correspond le mieux à vos besoins
- Une réponse simple doit être marquer le DLL pour copier local et utiliser un dossier comme Assemblies dans le même dossier de la solution et référence "Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll")
- Installez Visual Studio sur votre serveur de build. Cela semble fou, mais c'est le plus proche de la "machine de développeur" que vous avez.
- Installez le DLL dans le GAC afin que vous n'ayez pas à vous en préoccuper.
- Corrigez le package NuGet (Ajout d'une référence pour la version .NET Framework) et utilisez-le.
- Rétrogradez votre version de .NET Framework pour pouvoir utiliser le package NuGet.
- Créez votre propre serveur NuGet! (et ajoutez la référence des DLL dont vous avez besoin).
À mon humble avis, je choisirais la première réponse, car il semble que ce soit la "meilleure façon" d'utiliser NuGet pour résoudre tous les problèmes de vos packages mais vous utilisez un DLL que vous ne savez pas si il faut lui faire confiance.
Dans un système utilisé dans des "anciens" langages comme C ou C++, il est courant de télécharger le code source et les bibliothèques nécessaires pour que le code s'exécute, donc je ne pense pas que le package NuGet soit la meilleure solution.
En utilisant la première option, vous avez toujours la même version et pouvez vérifier le MD5 du fichier et savoir exactement ce qui fonctionne sur votre serveur de build.
Peut-être que la meilleure option devrait être 6. Lorsque vous utilisez votre propre serveur NuGet pour gérer vos DLL, ce qui rend votre vie plus impressionnante et plus fiable.
Pour les projets créés dans VS 2017. L'ajout du package Nuget Microsoft.VisualStudio.QualityTools.UnitTestFramework.Updated permet de construire des projets de test unitaire sur CI sans VS installé sur le serveur de build:
J'avais ce problème lorsque j'essayais d'utiliser MSBuild sur notre serveur de développement via notre processus CI/CD après avoir été invité à désinstaller VS2013 de notre serveur de développement par notre équipe informatique.
Dans mon cas, dans ma sortie de génération, il y avait quelques lignes avec le mot considéré. Cela signifie que la construction prend en compte les dossiers pour les emplacements où le fichier peut être localisé. L'une de ces lignes était la suivante:
Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll", but it didn't exist.
J'ai copié Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll de ma machine locale vers ce dossier sur le serveur de développement et l'erreur a disparu.