Meilleures pratiques pour les solutions de grande envergure dans Visual Studio (2008)

Question

Nous avons une solution avec plus de 100 projets, la plupart en C#. Naturellement, cela prend beaucoup de temps à ouvrir et à construire, et je suis donc à la recherche des meilleures pratiques pour de telles bêtes. Les questions auxquelles j'espère obtenir des réponses sont les suivantes :

• comment gérer au mieux les références entre les projets

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

• Chaque projet doit-il être construit dans son propre dossier ou doivent-ils tous être construits dans le même dossier de sortie (ils font tous partie de la même application) ?

• Les dossiers "solutions" sont-ils un bon moyen d'organiser les choses ?

Je sais qu'il est possible de diviser la solution en plusieurs solutions plus petites, mais cela s'accompagne de son propre lot de maux de tête liés à la refonte et à la construction, alors peut-être pouvons-nous garder cela pour un fil de discussion séparé :-)

Answer 1

Ces deux articles sur MSBuild que j'ai rédigés pourraient vous intéresser.

MSBuild : Meilleures pratiques pour créer des constructions fiables, partie 1

MSBuild : Meilleures pratiques pour créer des constructions fiables, partie 2

Plus précisément, la partie 2 comporte un article Construire de grandes arborescences de sources que vous pourriez souhaiter consulter.

Pour répondre brièvement à vos questions :

• CopyLocal ? Il est certain que cette option doit être désactivée.
• Construire vers un ou plusieurs dossiers de sortie ? Création d'un dossier de sortie
• Dossiers de solutions ? C'est une question de goût.

Sayed Ibrahim Hashimi

Mon livre : Inside the Microsoft Build Engine : Utilisation de MSBuild et Team Foundation Build

Answer 2

+1 pour épargnant l'utilisation de dossiers de solutions pour aider à organiser les choses.

+1 pour la construction du projet dans son propre dossier. Nous avons d'abord essayé un dossier de sortie commun, ce qui peut conduire à des références obsolètes subtiles et difficiles à trouver.

A titre d'information, nous utilisons les références de projet pour les solutions, et bien que nuget soit probablement un meilleur choix de nos jours, j'ai trouvé que svn:externals fonctionnait bien pour les assemblages tiers et les assemblages internes (de type framework). Il faut juste prendre l'habitude d'utiliser un numéro de révision spécifique au lieu de HEAD quand on fait référence à svn:externals (coupable :)

Answer 3

Déchargez-vous des projets que vous n'utilisez pas souvent et achetez un SSD. Un SSD n'améliore pas le temps de compilation, mais Visual Studio devient deux fois plus rapide à ouvrir/fermer/construire.

Answer 4

Nous avons un problème similaire car nous avons 109 projets distincts à gérer. Pour répondre aux questions initiales sur la base de nos expériences :

1. Comment gérer au mieux les références entre les projets ?

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

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

Notre expérience nous a appris qu'il n'y a pas de problème. La copie supplémentaire ne fait qu'allonger les délais de construction.

3. Chaque projet doit-il être compilé dans son propre dossier ou doivent-ils tous être compilés dans le même dossier de sortie (ils font tous partie de la même application) ?

Tous nos résultats sont placés dans un dossier unique appelé "bin". L'idée est que ce dossier soit 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 celle du déploiement.

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

Non, d'après notre expérience. La structure des dossiers d'une personne est le cauchemar d'une autre. Les dossiers profondément imbriqués ne font qu'augmenter le temps nécessaire pour trouver quoi que ce soit. Nous avons une structure complètement plate, mais nous nommons nos fichiers de projet, nos assemblages et nos espaces de noms de la même manière.

---

Notre façon de structurer les projets repose sur un fichier de solution unique. La construction de ce fichier prend beaucoup de temps, même si les projets eux-mêmes n'ont pas changé. Pour y remédier, nous créons généralement un autre fichier de solution "ensemble de travail actuel". Tous les projets sur lesquels nous travaillons y sont ajoutés. Les temps de construction sont considérablement améliorés, bien qu'un problème que nous avons constaté est qu'Intellisense échoue pour les types définis dans les projets qui ne font pas partie de l'ensemble actuel.

Un exemple partiel de la présentation de notre 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 5

Nous travaillons ici sur un projet similaire de grande envergure. Solution folders s'est avéré être un bon moyen d'organiser les choses, et nous avons tendance à laisser copy local à true. Chaque projet se construit dans son propre dossier, et nous savons alors que pour chaque projet déployable qui s'y trouve, nous avons le bon sous-ensemble de binaires en place.

Pour ce qui est de l'ouverture et de la construction du temps, il sera difficile d'y remédier sans passer par des solutions plus petites. Vous pourriez envisager de paralléliser la construction (google "Parallel MS Build" pour un moyen de le faire et de l'intégrer dans l'interface utilisateur) afin d'améliorer la vitesse ici. De plus, examinez la conception et voyez si le fait de remanier certains de vos projets afin d'en réduire le nombre global pourrait vous aider.