MSBuild speedup: comment supprimer les builds de projet inutiles?

J'ai une solution avec plusieurs projets dedans. Disons queMSBuild speedup: comment supprimer les builds de projet inutiles?

projet A dépend des projets B et C projet

B dépend de projet C

Quand je lance ma solution sur la machine locale VS construit chaque projet une fois et il faut 1 minute. Cependant, sur notre machine de construction, il faut environ 4 minutes pour construire et, comme je peux comprendre à partir des journaux MSBuild il va comme ceci:

build A -> construire B A, construire C A

build B -> construire C pour B

Donc, il construit plusieurs projets plusieurs fois ... Comment puis-je accélérer le processus de construction?

P.S. Ce n'est pas une question de 3 minutes supplémentaires, je me demande juste pourquoi est-ce si différent de ma machine locale?

Source

2009-06-08 Max Galkin

Quels outils utilisez-vous pour construire sur votre machine de construction? Pouvez-vous contrôler manuellement l'ordre de construction? – dss539

J'ai un fichier de configuration pour msbuild, qui spécifie SolutionToBuild ... d'autres choses, mais pas d'ordre de construction particulier. –

peut être que vous faites reconstruire sur le serveur et construire seulement sur votre machine – Uday

Je ne suis pas sûr de votre commande de build. Parfois, TeamBuild peut sembler construire des projets encore et encore mais il est en train de construire pour différentes configurations. Jetez un coup d'oeil et assurez-vous que vous n'avez pas défini plusieurs FlavorsToBuild. De plus, si vous ne voulez pas faire une nouvelle extraction et une reconstruction à chaque fois, vous pouvez le définir en bas de votre fichier TFSBuild.

<PropertyGroup> 
    <IncrementalBuild>true</IncrementalBuild> 
</PropertyGroup>-->

Mettre ce droit avant la balise </Project>.

Source

2009-06-09 14:49:30 Vaccano

Par la description dans MSDN je peux voir que c'est exactement ce dont j'ai besoin: une construction incrémentielle. Toujours ajouter cette balise au fichier de configuration n'a rien changé ... Dois-je aller plus loin et jouer avec les entrées/sorties? Ou peut-être quelque chose ne va pas avec les chemins dans mon environnement afin msbuild ne peut pas voir les fichiers construits précédemment? ... http://msdn.microsoft.com/en-us/library/ms171483.aspx –

Peut-être comme le notre, votre serveur de construction est une machine virtuelle (10x au moins plus lente).

Aussi TFS (et peut-être d'autres), fait un nouveau checkout sur la construction, de sorte qu'il devra construire tous les projets indépendamment.

Source

2009-06-08 15:59:32 leppie

Nous construisons dans la machine virtuelle - HyperV - et il y a peu de différence en comparant à la machine normale ... Une fois que nous avons déplacé le projet sur le disque SCSI (virtuel) est. Les disques IDE HyperV sont sloooow. – bh213

Utilisez-vous le commutateur/maxcpucount? Il peut y avoir une différence de nombre de processeurs entre votre machine locale et la machine de build. Ce paramètre peut également être différent entre votre fichier msbuild et le paramètre Visual Studio, ce qui peut également expliquer la différence que vous constatez dans les temps de construction.

Source

2009-07-12 19:31:26 JNappi

Cet échantillon semble fonctionner pour moi. TestLib.Extra dépend de TestLib. Si je change quelque chose dans TestLib, les deux projets vont se construire. Si je ne change que dans TestLib.Extra, seulement celui-là va construire, et si je ne change rien du tout, ils vont simplement rapporter en ignorant la cible "CoreCompile" parce que tous les fichiers de sortie sont à jour et ainsi de suite .

<Target Name="Build"> 
    <MSBuild Targets="Build" Projects="TestLib\TestLib.csproj" /> 
    <MSBuild Targets="Build" Projects="TestLib.Extra\TestLib.Extra.csproj" /> 
</Target>

L'astuce consiste à utiliser la cible "Build" des projets, plutôt que "Rebuild". La différence entre ceux-ci est essentiellement la même que la différence entre les commandes "Build" et "Reconstruire" dans le menu de construction dans Visual Studio.

Modifier

Cela fonctionne bien aussi si les projets sont inclus dans un fichier de solution, et que vous spécifiez la solution pour construire à la place:

<Target Name="Build"> 
    <MSBuild Targets="Build" Projects="TestLib.sln" /> 
</Target>

Source

2009-07-15 11:28:21

Hmmm .. J'utilise la commande "SolutionToBuild". Comme dans MSDN: http://msdn.microsoft.com/en-us/library/ms181718(VS.80).aspx –

@Yacoder: SolutionToBuild n'est pas une commande; il spécifie simplement les fichiers et les associe avec le nom "SolutionToBuild". Ce nom sera utilisé ailleurs dans le script msbuild pour effectuer la construction proprement dite. C'est là que vous pourriez être en mesure de faire ce que je montre dans mon échantillon. –

Je le fais comme suit.C'est un système de construction personnalisé un peu compliqué mais l'idée de base est.

Les DLL qui sont réutilisées dans de nombreuses solutions sont créées dans un dossier connu. Ceci est réalisé en utilisant un fichier de projet msbuild qui construit ces DLL communes.
Lors de la construction d'autres fichiers csproj dans une solution on copie les fichiers csproj utilisent alors la manipulation de xslt pour remplacer les références de projet avec refernces dll pour les dll communes.
Les scripts de construction construisent ensuite ces fichiers csproj modifiés en utilisant des fichiers de projet msbuild personnalisés que nous maintenons correspondant à chaque solution. Nous ne construisons pas de fichiers .sln. Ces fichiers de projet personnalisés sont un groupe de fichiers .csproj dans l'ordre de dépendance correct.

Peut-être que cela peut vous aider à atteindre ce que vous voulez.

Source

2009-07-15 11:47:56 softveda

MSBuild speedup: comment supprimer les builds de projet inutiles?

Répondre

Questions connexes