Meilleures pratiques pour les solutions volumineuses dans Visual Studio (2008)

Question

Nous avons une solution avec environ 100 projets, la plupart en C#. Naturellement, il faut beaucoup de temps pour ouvrir et construire, donc je suis à la recherche de meilleures pratiques pour ces bêtes. Le long des lignes de questions que j'espère obtenir des réponses à, sont:

• comment voulez-vous les meilleures références de la poignée entre les projets
  • pour des « copie locale » être activé ou désactivé?

• devrait tout projet de construire à son propre dossier, ou devraient-ils construire tous dans le même dossier de sortie (ils font tous partie de la même application)

• sont les dossiers de solutions une bonne façon d'organiser des trucs?

Je sais que la division la solution dans plusieurs petites solutions est une option, mais qui vient avec son propre ensemble de maux de tête de refactoring et de construction, donc nous pouvons peut-être sauf que pour un thread séparé :-)

Answer 1

Nous travaillons sur un grand projet similaire ici. Les dossiers de solution se sont révélés être un bon moyen d'organiser les choses, et nous avons tendance à laisser la copie locale à true. Chaque projet construit dans son propre dossier, et nous savons que pour chaque projet déployable nous avons le sous-ensemble correct des binaires en place. En ce qui concerne l'ouverture du temps et l'établissement du temps, il sera difficile de régler ce problème sans casser les petites solutions. Vous pourriez étudier paralléliser la construction (google "Parallel MS Build" pour une façon de le faire et de l'intégrer dans l'interface utilisateur) pour améliorer la vitesse ici. En outre, regardez la conception et voyez si la refactorisation de certains de vos projets pour aboutir à une réduction globale pourrait vous aider.

Answer 2

En termes d'allégement de la construction, vous pouvez utiliser l'option "Configuration Manager ..." pour les builds afin d'activer ou de désactiver la construction de projets spécifiques. Vous pouvez avoir un "Projet [n] Build" qui pourrait exclure certains projets et l'utiliser lorsque vous ciblez des projets spécifiques. En ce qui concerne les 100+ projets, je sais que vous ne voulez pas être martelé dans cette question sur les avantages de réduire la taille de votre solution, mais je pense que vous n'avez aucune autre option quand il s'agit d'accélérer temps de chargement (et l'utilisation de la mémoire) de devenv.

Answer 3

+1 pour épargner utiliser des dossiers de solution pour aider à organiser des choses.

+1 pour la création de projet dans son propre dossier. Nous avons d'abord essayé un dossier de sortie commun et cela peut conduire à des références périmées et douloureuses. FWIW, nous utilisons des références de projet pour les solutions, et bien que nuget soit probablement un meilleur choix ces jours-ci, nous avons trouvé que svn: externals fonctionne bien pour les assemblages internes de type tiers et de type (framework). Prenez l'habitude d'utiliser un numéro de révision spécifique au lieu de HEAD lorsque vous référencez svn: externals (coupable comme étant chargé :)

Answer 4

Ce que je fais typiquement avec ceci dépend un peu du processus de "débogage". Typiquement, bien que je ne mets pas la copie locale à true. Je configure le répertoire de construction pour chaque projet pour tout sortir au point final désiré.

Par conséquent, après chaque génération, j'ai un dossier rempli avec toutes les DLL et toutes les applications Windows/Web et tous les éléments sont à l'emplacement approprié. La copie locale n'était pas nécessaire puisque la DLL finissait au bon endroit à la fin.

Remarque

Les travaux ci-dessus pour mes solutions, qui sont typiquement des applications web et je ne l'ai pas connu des problèmes avec des références, mais il pourrait être possible!

Answer 5

Nous avons un problème similaire. Nous le résolvons en utilisant des solutions plus petites. Nous avons une solution maîtresse qui ouvre tout. Mais perf. c'est mauvais. Ainsi, nous segmentons les solutions plus petites par type de développeur. Ainsi, les développeurs de DB ont une solution qui charge les projets qui leur tiennent à cœur, les développeurs de services et les développeurs d'interface utilisateur de la même chose. C'est rare quand quelqu'un doit ouvrir toute la solution pour obtenir ce dont ils ont besoin au jour le jour. Ce n'est pas une panacée - il y a des avantages et des inconvénients. Voir "modèle multi-solution" in this article (ignorer la partie sur l'utilisation de VSS :)

Answer 6

Nous avons un problème similaire car nous avons 109 projets distincts à traiter. Pour répondre aux questions originales basées sur nos expériences:

1. Comment meilleures références de la poignée entre les projets

-vous que nous utilisons l'option de menu contextuel "ajouter une référence. Si 'projet' est sélectionné, la dépendance est ajoutée à notre unique fichier de solution global par défaut.

2. La fonction "copie locale" doit-elle être activée ou désactivée?

Dans notre expérience. La copie supplémentaire ajoute juste aux temps de construction.

3. Si chaque projet de construire à son propre dossier, ou devraient-ils construire tous dans le même dossier de sortie (ils font tous partie de la même application)

Tous notre production est mis en une seule dossier appelé «bin». L'idée étant que ce dossier est le même que lorsque le logiciel est déployé. Cela permet d'éviter les problèmes qui surviennent lorsque la configuration du développeur est différente de la configuration du déploiement.

4. Les dossiers de solutions sont-ils un bon moyen d'organiser les choses?

Aucun dans notre expérience. La structure de dossiers d'une personne est le cauchemar d'une autre personne. Les dossiers profondément imbriqués augmentent simplement le temps nécessaire pour trouver quoi que ce soit. Nous avons une structure complètement plate mais nous donnons le même nom à nos fichiers de projet, nos assemblages et nos espaces de noms.

---

Notre façon de structurer les projets repose sur un seul fichier de solution. Construire cela prend beaucoup de temps, même si les projets eux-mêmes n'ont pas changé. Pour aider à cela, nous créons généralement un autre fichier de solution «jeu de travail en cours». Tous les projets sur lesquels nous travaillons sont ajoutés à cela. Les temps de construction sont considérablement améliorés, bien qu'un problème que nous avons vu est que Intellisense échoue pour les types définis dans les projets qui ne sont pas dans l'ensemble actuel.

Un exemple partiel de notre mise en page de la solution:

\bin 

OurStuff.SLN 

OurStuff.App.Administrator 
OurStuff.App.Common 
OurStuff.App.Installer.Database 
OurStuff.App.MediaPlayer 
OurStuff.App.Operator 
OurStuff.App.Service.Gateway 
OurStuff.App.Service.CollectionStation 
OurStuff.App.ServiceLocalLauncher 
OurStuff.App.StackTester 
OurStuff.Auditing 
OurStuff.Data 
OurStuff.Database 
OurStuff.Database.Constants 
OurStuff.Database.ObjectModel 
OurStuff.Device 
OurStuff.Device.Messaging 
OurStuff.Diagnostics 
... 
[etc] 

Answer 7

Je pense que des solutions ce grand les meilleures pratiques devrait être de les briser. Vous pouvez penser à la «solution» comme un endroit pour rassembler les projets nécessaires et peut-être d'autres pièces pour travailler sur une solution à un problème. En divisant les 100+ projets en plusieurs solutions spécialisées pour développer des solutions pour seulement une partie du problème global, vous pouvez traiter avec moins de temps en accélérant vos interactions avec les projets requis et en simplifiant le domaine du problème. Chaque solution produirait la sortie dont elle est responsable.

Cette sortie doit avoir des informations de version qui peuvent être définies dans un processus automatisé. Lorsque la sortie est stable, vous pouvez mettre à jour les références dans les projets dépendants et les solutions avec la dernière distribution interne. Si vous voulez toujours entrer dans le code et accéder à la source, vous pouvez le faire avec le serveur de symboles Microsoft que Visual Studio peut utiliser pour vous permettre d'accéder aux assemblys référencés et même de récupérer le code source.

Le développement simultané peut être effectué en spécifiant des interfaces en amont et en se moquant des assemblages en développement pendant que vous attendez des dépendances qui ne sont pas complètes mais que vous souhaitez développer. Je trouve que c'est une bonne pratique car il n'y a pas de limite à la complexité de l'effort global lorsque vous le décomposez physiquement de cette manière. Mettre tous les projets dans une solution unique atteindra finalement une limite supérieure.

Espérons que cette information vous aide.

Answer 8

Nous avons environ 60+ projets et nous n'utilisons pas de fichiers de solution. Nous avons un mélange de projets C# et VB.Net. La performance a toujours été un problème. Nous ne travaillons pas sur tous les projets en même temps. Chaque développeur crée ses propres fichiers de solution en fonction des projets sur lesquels il travaille. Les fichiers de solution ne sont pas vérifiés dans notre contrôle source.

Tous les projets de bibliothèque de classes sont générés dans un dossier CommonBin à la racine du répertoire source. Les projets exécutables/Web sont créés dans leur dossier individuel.

Nous n'utilisons pas les références de projet, mais la référence basée sur les fichiers du dossier CommonBin. J'ai écrit une tâche MSBuild personnalisée qui inspecterait les projets et déterminerait l'ordre de construction.

Nous l'utilisons depuis quelques années maintenant et nous n'avons rien à redire.

Answer 9

Vous pouvez être intéressé par ces deux articles MSBuild que j'ai écrits.

MSBuild: Best Practices For Creating Reliable Builds, Part 1

MSBuild: Best Practices For Creating Reliable Builds, Part 2

specificially dans la partie 2, il y a une section construction de grands arbres source que vous pourriez jeter un coup d'oeil.

Pour répondre brièvement à vos questions ici si:

• CopyLocal? Éteignez-le bien
• Créer un ou plusieurs dossiers de sortie? Créer un dossier de sortie
• Dossiers de solution? C'est une question de goût.

Sayed Ibrahim Hashimi

Mon livre: Inside the Microsoft Build Engine : Using MSBuild and Team Foundation Build

Answer 10

projets Décharger vous n'utilisez pas souvent, et d'acheter un SSD. Un SSD n'améliore pas le temps de compilation, mais Visual Studio devient deux fois plus rapide pour ouvrir/fermer/construire.

Answer 11

Tout cela a à voir avec votre définition et votre vision de ce qu'est une solution et un projet. Dans mon esprit, une solution est juste cela, un regroupement logique de projets qui résolvent une exigence très spécifique. Nous développons une grande application Intranet. Chaque application de cet intranet a sa propre solution, qui peut également contenir des projets pour les services exes ou windows. Et puis nous avons un cadre centralisé avec des choses comme les classes de base et les helpers et httphandlers/httpmodules. Le cadre de base est assez grand et est utilisé par toutes les applications. En divisant les nombreuses solutions de cette manière, vous réduisez le nombre de projets requis par une solution, car la plupart d'entre eux n'ont rien à voir l'un avec l'autre. Avoir autant de projets dans une solution est juste une mauvaise conception. Il ne devrait y avoir aucune raison d'avoir autant de projets dans une solution. L'autre problème que je vois est avec les références de projet, ils peuvent vraiment vous bousiller finalement, surtout si vous voulez diviser votre solution en plus petits.

Mon conseil est de le faire et de développer un cadre centralisé (votre propre implémentation de la bibliothèque d'entreprise si vous voulez). Vous pouvez le partager avec GAC ou vous pouvez directement référencer l'emplacement du fichier pour avoir un magasin central. Vous pouvez également utiliser la même tactique pour les objets métier centralisés.

Si vous voulez référencer directement la DLL, vous voudrez la référencer dans votre projet avec copy local false (quelque part comme c: \ mycompany \ bin \ mycompany.dll). Une exécution vous devrez ajouter quelques paramètres à votre app.config ou web.config pour faire référence à un fichier qui ne se trouve pas dans le GAC ou dans le chutier d'exécution. Dans tous les cas, cela n'a pas d'importance s'il s'agit d'une copie locale ou non, ou si la DLL se retrouve dans la corbeille ou même dans le GAC, car la configuration va surcharger les deux. Je pense que c'est une mauvaise pratique de copier localement et avoir un système désordonné. Vous devrez probablement copier localement temporairement si vous avez besoin de déboguer dans l'un de ces assemblages.

Vous pouvez lire mon article sur l'utilisation globale d'une DLL sans le GAC. Je n'aime vraiment pas le GAC principalement parce qu'il empêche le déploiement de xcopy et ne déclenche pas un redémarrage automatique sur les applications.

http://nbaked.wordpress.com/2010/03/28/gac-alternative/

Answer 12

Set CopyLocal = false va réduire le temps de construction, mais peut causer différents problèmes pendant le temps de déploiement.

Il existe de nombreux scénarios, lorsque vous avez besoin de Copier Local 'à Vrai, par ex. Projets de niveau supérieur, Dépendances de second niveau, DLL appelées par réflexion.

Mon expérience avec la définition de CopyLocal = false a échoué. Voir le résumé des avantages et inconvénients dans mon blog "Do NOT Change "Copy Local” project references to false, unless understand subsequences."