Référence Microsoft.VisualStudio.QualityTools.UnitTestFramework pour la génération de CI

J’ai créé un projet de test C # dans VS2015 RC. il se construit localement mais lorsque je tente de construire sur notre serveur de build CI (TeamCity), il échoue avec des erreurs:

UnitTest1.cs (2,17): erreur CS0234: le type ou le nom d’espace de noms ‘VisualStudio’ n’existe pas dans l’espace de noms ‘Microsoft’ (il vous manque une référence d’assembly?) [D: \ BuildAgent \ work \ e486bf18e454d0c2 \ dh. PSP.Coordinator.Api.Tests \ dh.PSP.MetadataService.Api.Tests.csproj] UnitTest1.cs (9,10): erreur CS0246: le nom du type ou de l’espace de noms ‘TestMethod’ est introuvable (utilisez-vous directive ou une référence d’assembly?) [D: \ BuildAgent \ work \ e486bf18e454d0c2 \ dh.PSP.Coordinator.Api.Tests \ dh.PSP.MetadataService.Api.Tests.csproj] UnitTest1.cs (9,10): error CS0246 : Le type ou nom de l’espace de noms ‘TestMethodAtsortingbute’ est introuvable (il manque une directive using ou une référence d’assembly?) [D: \ BuildAgent \ work \ e486bf18e454d0c2 \ dh.PSP.Coordinator.Api.Tests \ dh.PSP. MetadataService.Api.Tests.csproj] UnitTest1.cs (6,6): erreur CS0246: le nom de type ou d’espace de nom ‘TestClass’ n’a pas pu être trouvé (il manque une directive using ou une référence d’assembly?) [D: \ BuildAgent \ work \ e486bf18e454d0c2 \ dh.PSP.Co ordinator.Api.Tests \ dh.PSP.MetadataService.Api.Tests.csproj] UnitTest1.cs (6,6): erreur CS0246: Le nom de type ou d’espace de nom ‘TestClassAtsortingbute’ n’a pas pu être trouvé (vous avez oublié une directive d’utilisation ou une référence d’assembly?) [D: \ BuildAgent \ work \ e486bf18e454d0c2 \ dh.PSP.Coordinator.Api.Tests \ dh.PSP.MetadataService.Api.Tests.csproj]

Clairement, cela est dû au fait que l’assembly contenant ces espaces de noms (Microsoft.VisualStudio.QualityTools.UnitTestFramework) n’est pas sur le serveur de génération, il se trouve sur mon ordinateur local à l’emplacement C: \ Program Files (x86) \ Microsoft Visual Studio 12.0 \ Common7 \ IDE \ PublicAssemblies \ Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll. Je suppose que je pourrais copier l’assembly dans ma solution pour qu’il devienne une partie de la base de code, mais le déplacement manuel de fichiers donne l’impression d’être un peu un piratage peu élégant. J’ai cherché sur le nuget et trouvé http://www.nuget.org/packages/Microsoft.VisualStudio.QualityTools.UnitTestFramework/ dont j’ai pensé qu’il ferait l’affaire, mais l’installation de ce paquet 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 cadre.

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 un peu comme un débutant).

Hmm, j’ai quelques idées, alors choisissez celle qui correspond le mieux à vos besoins

  1. Une réponse simple doit marquer la DLL pour la copie locale et utiliser un dossier tel que Assemblies dans le même dossier de la solution et faire référence à “Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll”.
  2. Installez Visual Studio sur votre serveur de génération. Cela semble fou, mais c’est la machine la plus proche de la “machine développeur” que vous avez.
  3. Installez la DLL dans le GAC afin que vous n’ayez pas à vous en préoccuper.
  4. Corrigez le package NuGet (Ajout d’une référence pour la version .NET Framework) et utilisez-le.
  5. Déclassez votre version .NET Framework pour pouvoir utiliser le package NuGet.
  6. Créez votre propre serveur NuGet! (et ajoutez la référence des DLL dont vous avez besoin).

IMHO Je choisirais la première réponse, car elle semble être le “meilleur moyen” d’utiliser NuGet pour résoudre tous vos problèmes de paquets, mais vous utilisez une DLL dont vous ne savez pas s’il convient de faire confiance.

Dans les systèmes utilisés dans les “anciens” langages tels que C ou C ++, il est courant de télécharger le code source et les bibliothèques nécessaires à son exécution. Je ne pense donc pas que le package NuGet soit la meilleure solution.

En utilisant la première option, vous avez toujours la même version et pouvez consulter le MD5 du fichier et savoir exactement ce qui est exécuté sur votre serveur de build.

Peut-être que la meilleure solution devrait être 6. Lorsque vous utilisez votre propre serveur NuGet pour gérer vos DLL, votre vie devient plus impressionnante et plus fiable.

La réponse est similaire à l’option 1 de la réponse de eng.augusto .
Microsoft ne fournit pas NuGet pour la dernière version de Microsoft.VisualStudio.QualityTools.UnitTestFramework, mais le fournit en tant que partie de Visual Studio ( normalement sous 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 source (même si les DLL sont généralement ignorées).
Ensuite, j’ai changé les références dans mon Test.csproj pour faire référence à un nouvel emplacement.

Pour les projets créés dans VS 2017. Ajouter le package Nuget Microsoft.VisualStudio.QualityTools.UnitTestFramework.Updated permet de générer des projets de tests unitaires sur un CI sans installation de VS sur le serveur de génération:

entrez la description de l'image ici