J'ai une grande solution, de quelque 320 projets, où même de petites modifications apportées à un seul formulaire Web entraînent des temps de construction longue pour tester / déboguer un petit changement. Je soupçonne des tâches de copie de fichier post-build pour "toucher" DateTimes de fichier et provoquant plusieurs reconstructions.
Y a-t-il d'autres raisons pour VS 2010 pour exécuter une reconstruction autre que les fichiers source étant plus récente que les fichiers de sortie binaires, en l'absence de fortes influences de nommage et de versions?
addendum: je n'ai aucune influence immédiate sur la taille ou la forme de l'arborescence source. Il s'agit du tronc d'un produit de base stable et de tout changement «non commercial» à court terme sont considérés comme risqués et coûteux. Je vais soulever des points mentionnés dans les réponses que je reçois ici en tant que contribution aux directives futures du projet.
5 Réponses :
320 projets est beaucoup de fichiers dans l'arborescence de dépendance: tous doivent être vérifiés pour des modifications par le moteur de construction. En utilisant quelque chose comme moniteur de processus vous permettra de voir quelles opérations de fichier se déroulent Confirmez ceci.
Aussi 320 assemblages (en haut des assemblages de framework .NET) à la charge au moment de l'exécution ralentiront votre application et ralentissez vraiment le débogueur (beaucoup de symboles à charger). Regardez le débogage | Windows | Modules pour voir les modules chargés).
Ainsi que la réduction du nombre de projets dans la solution (il est tout à fait possible d'avoir plusieurs solutions chacune avec un sous-ensemble des projets) Avez-vous vraiment besoin de nombreux projets distincts? En dehors du débogueur, le chargeur .NET ne charge que et jette le code des assemblys tel qu'il est nécessaire, les ensembles plus importants ne signifient pas de temps de charge plus lente et évitez les frais généraux par montage du chargeur Windows.
Je crois qu'ils peuvent aider ce dernier point sur une étape d'iLmere post-construit
C # reconstruit parce qu'un fichier a été modifié ou une dépendance a été modifiée, mais aussi fréquemment pour "aucune raison évidente". Vous pouvez souvent construire 2 ou 3 fois de suite sans fabriquer un seul changement et C # va rouder et reconstruire de vastes quantités du code.
Tourner les outils> Options> Projets et solutions> Construire et exécuter> Ne construisez que des projets de démarrage et des dépendances en cours d'exécution. Cela minimisera la construction uniquement aux dépendances du projet que vous avez l'intention d'exécuter, de sorte que tout soit un arbre de dépendance massif, cela réduira considérablement le nombre de projets considérés dans la construction.
La meilleure solution, cependant, est d'éviter de lui demander de compiler en premier lieu.
Chaque projet ajoute une surcharge supplémentaire à la construction. Sur mon PC, c'est environ 3 secondes. En fusionnant le code de deux projets en un fichier .csproj, j'ai économisé 3 secondes de la durée de construction. Ainsi, pour plus de 300 projets, vous pouvez frapper 10 minutes du temps de construction juste en fusionnant des projets - c'est-à-dire si possible d'utiliser de nombreux modules / espaces de noms dans un assemblage plutôt que de nombreux assemblages. Vous trouverez que votre temps de démarrage de l'application est également amélioré.
De nombreux projets n'ont pas besoin de construire tout le temps. Cassez-les comme des projets de bibliothèque et il suffit de créer un lien vers (Référence) les fichiers binaires
désactiver également "la copie locale" et pointez toutes les sortiesPaths vers un dossier partagé - cela réduira de manière significative les frais généraux en évitant la fabrication de 320 copies de 320 dll sur votre disque dur.
Ajouter de nouvelles configurations de version (par exemple "" Débug Fastbuild ") qui ne construisent que les assemblages que vous travaillez réellement. Avec le gestionnaire de configuration, vous pouvez défendre les projets que vous ne voulez pas créer, et PRESTO, ils sont ignorés par le système de construction. Après avoir obtenu le code de Source Control, créez une construction complète de «débogage» pour tout rafraîchir, puis revenez à «Fastbuild»
Merci pour toi des conseils de base, je sais que les petits twicks peuvent venir très en main lors de la construction de grandes solutions.
Les "raisons évidentes" incluent une modification de la configuration de construction (x86 / x64, débogage / release), qui semble créer faussement un fichier "build.force" dans le dossier obj : DeveloperCommunity.VisualStudio.com/t/...
Vous pouvez essayer de construire votre solution à l'aide de MSBUILD et / V: D (pour la journalisation de diagnostics).
Il peut y avoir des indices dans le journal pour la raison pour laquelle un projet n'est pas à jour.
Tout d'abord, vérifiez que les références à d'autres projets sont des références de projet et non des références d'assemblage.
Deuxièmement, vérifiez les références circulaires.
Troisième, définissez la verbosité de la journalisation du diagnostic et regardez la toute première ligne et voyez pourquoi il reconstruisant des projets après la construction de la solution pour la première fois.
Il y a beaucoup plus qui peut être vérifié, mais jetez un coup d'œil à ces 3 choses d'abord.
Je pense à 320 projets que vous avez dépassé longtemps la limite de ce que Visual Studio a été conçu pour faire confortablement.
Il y a beaucoup de bons conseils ici, mais si vous devez vraiment conserver 320 projets, vous voudrez peut-être dépenser votre studio Visual pour bâtir et concevoir votre propre processus de construction.
Comme je l'ai dit dans mon commentaire, sur Windows au moins, ma recommandation pour un outil de construction est PSKE Ce qui est construit sur PowerShell (et donc inclus sur chaque machine à Windows moderne), assez puissante et suffisamment légère pour engager la chose entière à votre contrôle source.
Je ne sais pas comment réparer votre problème de reconstruction spécifiquement, mais 320 projets dans une solution ne sont pas une bonne idée. Si j'étais vous, je posterais une question détaillant les catégories de projets, ce que les dépendances générales sont entre elles, demandant la meilleure façon de les rendre gérables.
Mon Dieu, 320 projets? Je frappe 10 une fois et c'était insupportable. Je suis tellement désolé. Pour vous aider, vous pouvez créer plusieurs solutions ou un processus de construction manuelle à l'aide d'un outil tel que PSKE qui paire Juste les projets essentiels pour un scénario donné.