Quelle est la meilleure façon de faire en sorte que TFS produise chaque projet dans son propre répertoire ?

Question

Je suis en train d'intégrer une importante base de code dans Team Foundation Server. Je voudrais que le processus de construction crée une construction "prête à déployer" de nos projets.

La façon normale de procéder consiste à placer les résultats de chaque projet dans son propre dossier. Ainsi, par exemple, nous nous retrouvons avec quelque chose comme

C:\project1\
            assembly1.dll
            assembly2.dll
            project1.exe
            project1.exe.config
C:\project2\
            assembly2.dll
            assembly3.dll
            project2.exe
            project2.exe.config
C:\project3\
            assembly1.dll
            assembly3.dll
            project3.exe
            project3.exe.config

C'est comme ça qu'on l'aime.

TFS, cependant, semble vouloir tout mettre dans le même répertoire.

C:\output\
          assembly1.dll
          assembly2.dll
          assembly3.dll
          project1.exe
          project1.exe.config
          project2.exe
          project2.exe.config
          project3.exe
          project3.exe.config

ce qui, bien que permettant d'économiser un peu d'espace disque (les assemblages ne sont présents qu'une fois chacun), n'est pas ce que nous voulons.

Quelle est la meilleure façon de spécifier où TFS/MSBuild doit placer les fichiers de sortie ? Dois-je modifier les fichiers sln/csproj individuellement pour y parvenir ou puis-je le faire dans le fichier TFSBuild.proj ? (c'est-à-dire dans un fichier spécifique à MSBuild)

Answer 1

Je viens de bloguer une autre méthode ici :

http://mikehadlow.blogspot.com/2009/06/tfs-build-publishedwebsites-for-exe-and.html mais si vous ne pouvez pas vous donner la peine de suivre le lien, voici le texte intégral :

C'est généralement une bonne pratique de rassembler tout le code sous le contrôle de votre équipe dans une seule uber-solution comme décrit dans ce PDF Patterns and Practices, Team Development with TFS Guide. Si vous configurez ensuite le serveur de construction TFS pour construire cette solution, le comportement par défaut est de placer le résultat de la construction dans un seul dossier, 'Release'.

Tous les projets d'application web de votre solution seront également publiés dans un dossier appelé _PublishedWebsites_. \. C'est très bien car cela signifie que vous pouvez simplement déployer l'application web par robocopie.

Malheureusement, il n'y a pas de comportement par défaut similaire pour les autres types de projets tels que WinForms, console ou bibliothèque. Ce serait très bien si nous pouvions avoir un sous-dossier _PublishedApplications\ avec la sortie de n'importe quel projet sélectionné. Heureusement, ce n'est pas si difficile à faire.

La façon dont _PublishedWebsites fonctionne est assez simple. Si vous regardez le fichier de projet de votre application web, vous remarquerez une importation vers le bas :

<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets" />

Sur ma machine la propriété MSBuildExtensionsPath évalue à C:\Program Fichiers \MSBuild Si nous ouvrons le fichier Microsoft.WebApplication.targets, nous pouvons voir qu'il s'agit d'un fichier MSBuild assez simple qui reconnaît quand le build n'est pas un build de bureau, c'est-à-dire un build TFS, et qui copie la sortie vers :

$(OutDir)_PublishedWebsites\$(MSBuildProjectName)

J'ai simplement copié le fichier Micrsoft.WebApplication.targets, je l'ai placé sous contrôle de source avec un chemin relatif à partir de mes fichiers de projet et j'ai changé _PublishedWebsites en _PublishedApplications et renommé le fichier CI.exe.targets. Pour chaque projet que je veux sortir vers _PublishedApplications, j'ai simplement ajouté cette importation au bas du fichier du projet :

<Import Project="<your relative path>\CI.exe.targets" />

Vous pouvez modifier CI.exe.targets (ou le nom que vous voulez lui donner) pour qu'il fasse ce que vous voulez. Dans mon cas, le seul changement jusqu'à présent est d'ajouter quelques lignes pour copier le fichier App.config :

<Copy SourceFiles="$(OutDir)$(TargetFileName).config" DestinationFolder="$(WebProjectOutputDir)\bin" SkipUnchangedFiles="true" />

Il y a beaucoup de choses dans Microsoft.WebApplication.targets qui ne sont pertinentes que pour les applications Web et qui peuvent être supprimées pour d'autres types de projets, mais je laisserai cela comme un exercice pour le lecteur.

Answer 2

TFS 2012+

J'aime cette solution...

Modifiez votre définition de construction. Sous la section Processus, définissez MSBuild arguments à

/p:GenerateProjectSpecificOutputFolder=true

Comme ça :

Answer 3

Par défaut, chaque fichier de projet (*.csproj, *.vbproj, etc.) spécifie un répertoire de sortie par défaut (qui est généralement bin \Debug , bin \Release etc.). En fait, Team Build prend le dessus sur cela pour que vous ne soyez pas soumis aux caprices des propriétés définies par le développeur dans le fichier de projet, mais aussi pour que Team Build puisse faire des suppositions sur l'emplacement des sorties.

La façon la plus simple de remplacer ce comportement est de définir CustomizableOutDir à true dans le groupe d'éléments SolutionToBuild comme indiqué ici :

<ItemGroup>
  <SolutionToBuild Include="$(BuildProjectFolderPath)\path\MySolution.sln" />
    <Properties>CustomizableOutDir=true</Properties>
  </SolutionToBuild>
</ItemGroup>

Ainsi, la structure du dossier de dépôt correspondra plus ou moins à ce que vous obtiendriez localement si vous construisiez la solution.

Cette méthode est nettement préférable au remplacement des cibles Core*, qui peut entraîner des problèmes de mise à niveau.

Answer 4

Pour chaque nœud SolutionToBuild, définissez la propriété OutDir sur $(OutDir) \SubFolder
Par exemple :

  <ItemGroup>
   <SolutionToBuild Include="Project1.sln" >
    <Properties>OutDir=$(OutDir)\Project1\</Properties>      
   </SolutionToBuild>
   <SolutionToBuild Include="Project2.sln" >
    <Properties>OutDir=$(OutDir)\Project2\</Properties>      
   </SolutionToBuild>
   <SolutionToBuild Include="Project3.sln" >
    <Properties>OutDir=$(OutDir)\Project3\</Properties>      
   </SolutionToBuild>
  <ItemGroup>

(Cela fonctionne dans TF2008, mais pas dans TF2005).

Answer 5

Mise à jour pour TFS 2010 (et bientôt TFS 2012). Jason Stangroome a rédigé un article de blog expliquant comment procéder.

https://blog.stangroome.com/2012/02/03/override-the-tfs-team-build-outdir-property/

Remplacez la propriété TFS Team Build OutDir.

Mise à jour : avec .NET 4.5, il existe une méthode plus simple. .

Une plainte très courante de la part des utilisateurs du système de construction de Team Foundation Server est qu'il modifie la structure des dossiers des sorties de projet. Par défaut, Visual Studio place tous les fichiers dans le dossier /bin/ ou /bin// respectif de chaque projet, mais Team Build utilise simplement une structure de dossier plate en plaçant tous les fichiers dans le dossier de dépôt Root ou, encore une fois, un sous-dossier // dans le dossier de dépôt, avec toutes les sorties de projet mélangées.

De plus, Team Build y parvient en définissant la propriété OutDir via la ligne de commande MSBuild.exe combinée avec La préséance des propriétés de MSBuild cette valeur ne peut pas être facilement modifiée à partir de MSBuild lui-même et la solution populaire est de modifier le fichier Build Process Template *.xaml pour utiliser un nom de propriété différent . Mais je préfère ne pas toucher au Workflow, sauf en cas de nécessité absolue.

Au lieu de cela, j'utilise les fonctionnalités Solution Before Target et Inline Task de MSBuild v4 pour remplacer l'implémentation par défaut de la tâche MSBuild utilisée pour construire les projets individuels dans la solution. Dans mon implémentation alternative, j'empêche la propriété OutDir d'être transmise et je transmets une propriété appelée PreferredOutDir à la place que les projets individuels peuvent utiliser si désiré.

La première partie, qui consiste à substituer la propriété OutDir à la propriété PreferredOutDir au niveau de la solution, s'effectue simplement en ajoutant un nouveau fichier au répertoire dans lequel se trouve votre fichier de solution. Ce nouveau fichier doit être nommé selon le modèle "before..sln.targets", par exemple pour un fichier de solution appelé "Foo.sln", le nouveau fichier sera "before.Foo.sln.targets". Le contenu de ce nouveau fichier doit être ressemble à ceci . Assurez-vous que ce nouveau fichier est archivé dans le contrôle de la source.

La deuxième partie, qui consiste à laisser chaque projet contrôler la structure de son dossier de sortie, consiste simplement à ajouter une ligne au fichier *.csproj ou *.vbproj du projet (selon la langue). Localisez le premier élément dans le fichier du projet qui n'a pas d'attribut Condition spécifié, et localisez la balise de fermeture correspondante pour cet élément. Immédiatement au-dessus de la balise de fermeture, ajoutez une ligne semblable à celle-ci :

<OutDir Condition=" '$(PreferredOutDir)' != '' ">$(PreferredOutDir)$(MSBuildProjectName)\</OutDir>

Dans cet exemple, le projet sera placé dans le dossier de dépôt Team Build, dans un sous-dossier portant le même nom que le fichier du projet (sans l'extension .csproj). Vous pouvez choisir un modèle différent. En outre, les projets Web créent généralement leur propre dossier de sortie dans un sous-dossier _PublishedWebSites du dossier de dépôt Team Build. Pour conserver ce comportement, il suffit de définir la propriété OutDir pour qu'elle soit exactement égale à la propriété PreferredOutDir.

Vous pouvez vérifier si vos changements ont fonctionné sur votre machine locale avant de vous enregistrer, simplement en exécutant MSBuild à partir de la ligne de commande et en spécifiant la propriété OutDir comme le fait Team Build, par exemple :

msbuild Foo.sln /p:OutDir=c:\TestDropFolder\