63 votes

Automatiser la création d'un paquet NuGet dans le cadre du processus de construction

J'ai un processus de construction automatisé que j'aimerais étendre pour pouvoir construire les bibliothèques que je distribue via NuGet. Actuellement, l'exécution de nuget.exe pour créer les paquets est une opération manuelle.

Quelle est la meilleure façon de configurer VS 2010 pour que mon fichier de package NuGet (*.nupkg) soit le résultat final d'une construction "Release" ?

N'oubliez pas que j'ai d'autres fichiers (contenu et outils) pour certains des paquets. Et, dans la plupart des cas, j'ai fusionné plusieurs projets en un seul paquet NuGet pour prendre en charge .NET 4, Silveright et Phone 7.

(Je dois préciser que le processus "automatisé" existant est un simple exécuteur de fichier batch qui construit une solution en utilisant la ligne de commande).

UPDATE

Je souhaite rafraîchir cette discussion car le problème n'a pas été résolu. Bien que le lien fourni par @pravin soit utile, il n'aborde pas le fait que j'ai plusieurs projets dans un seul paquet ainsi que d'autres contenus comme des scripts PowerShell, des transformations de configuration et de code source, etc.

Le meilleur exemple que je puisse utiliser est un assemblage qui possède à la fois une version .NET 4 et une version Silverlight 5. Celles-ci sont distribuées dans le même paquet. Je ne peux pas utiliser un événement post-build pour créer le package car celui-ci dépend de DEUX projets.

32voto

Josh Rack Points 307

Une chose qui pourrait bien fonctionner est de créer un fichier MSBuild .proj personnalisé. Vous pourriez définir quelques cibles dans le script personnalisé, la première pour exécuter la compilation sur votre solution. Une deuxième cible à exécuter après la compilation utiliserait la tâche EXEC MSBuild pour invoquer l'utilitaire de ligne de commande nuget.exe. Ensuite, vous mettez à jour votre exécuteur de fichiers batch pour exécuter l'exécutable msbuild en fournissant votre fichier de projet personnalisé comme argument. Vous utilisez peut-être déjà MSBuild dans votre script batch, ce qui dans ce cas serait simplement une question de permutation d'argument. Vous pourriez inclure votre fichier proj personnalisé dans les éléments de solution de votre solution. Si vous faites cela, vous pourriez facilement ajouter une référence d'outil externe dans Visual Studio pour tester rapidement votre script personnalisé afin de vous assurer qu'il construit et produit le paquet comme vous l'espérez.

Exemple de MSBuild

Vous pouvez vous en servir comme point de départ :

<Project DefaultTargets="Compile" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" >
    <PropertyGroup>
      <SolutionFile></SolutionFile>
      <NugetExecutable>C:\PathToNuget\nuget.exe</NugetExecutable>
      <NuspecFile></NuspecFile>
    </PropertyGroup>

    <Target Name = "Compile">
        <MSBuild Projects="$(SolutionFile)" Properties="Configuration=Release" />
    </Target>

    <Target Name = "Package">
    <!-- You could use the MSBuild Copy task here to move the compiled code into
           a structure that fits your desired package format -->
      <Exec Command="&quot;$(NugetExecutable)&quot; pack $(NuspecFile)" />
    </Target>
</Project>

On pourrait alors appeler ça comme ça :

"C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe" Build.proj /p:SolutionFile=PathToSolution\App.sln;NuspecFile=foo.nuspec

10voto

Schwarzie2478 Points 1006

Je fais déjà la chose que vous voulez réaliser dans mon projet actuel :

Chaque assemblage est construit dans son propre paquet nuget, avec les dépendances en place.

J'ai résolu le problème en créant un dossier de paquet dans le projet pour lequel je voulais créer un paquet nuget. Là, je configure un fichier nuspec avec les informations nécessaires sur le paquet nupkg

J'y crée tous les dossiers et les fichiers non modifiés nécessaires à la structure des paquets Nuget.

J'ai ajouté une étape de post-construction dans le projet qui copie les fichiers qui viennent d'être construits dans le dossier de paquetage et exécute nuget.exe

C'est ainsi :

  • Projet de construction.
  • Copier la sortie dans le paquet \Lib du projet.
  • Exécuter nuget.exe avec le fichier nuspec dans le dossier du paquet.
  • Copiez le résultat dans le dossier de sortie à côté du reste de la sortie.

Nuget.exe doit se trouver soit dans un dossier fixe de votre système y le serveur de construction (solution sale) ou inclus dans votre construction (moins sale).

Buildscript :

Xcopy.exe /Y "$(TargetPath)" "$(ProjectDir)\Package\Lib" 
cd "$(ProjectDir)Package" 
"$(TargetDir)..\Buildscripts\Nuget.exe" pack MyPackage.nuspec xcopy /Y *.nupkg "$(TargetDir)" 

Pour l'utiliser, la seule chose dont vous devez vous occuper, c'est de décider où enregistrer le nuget.exe. J'ai créé un dossier buildscripts au niveau supérieur de mon arbre de développement.

7voto

Alex Points 83

Si vous êtes dans un environnement TFS 2010, l'option Projet NuGetter devrait résoudre le problème de la création automatique de paquets nuget. Il crée un seul paquet pour l'ensemble de la construction. Il s'agit en fait d'un flux de travail de construction TFS 2010 qui fait le travail en appelant nuget.exe avec quelques arguments.

7voto

Brent M. Spell Points 1414

J'ai créé une extension Visual Studio de type projet NuGet (.nuproj) appelée NuBuild qui devrait faire ce que vous voulez. Elle vous permet de construire vos paquets NuGet à partir de Visual Studio ainsi que de MSBuild. Vous pouvez l'installer à partir du site galerie ou obtenir la source à github .

4voto

Matthew M. Osborn Points 1656

Installez le paquet NuGet Powertools dans votre sln et il ajoutera une cible de construction pour créer le nupkg puis modifiez simplement votre CI pour exécuter cette tâche également. http://nuget.org/packages/NuGetPowerTools

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X