Plusieurs applications dans une seule solution Visual Studio [fermé]


17

Je travaille pour une entreprise qui souhaite regrouper toutes ses applications .Net (applications Web, applications Windows et applications console) dans une seule solution Visual Studio.

Je recherche de l'expérience auprès de développeurs qui structurent leurs propres applications de cette manière ou qui travaillent dans une entreprise qui le fait. Est-ce une bonne idée?

  • Quels sont les avantages et les inconvénients de mettre toutes vos applications dans une seule solution plutôt que d'avoir des solutions distinctes pour chaque application?

  • Quelle est la vitesse de Visual Studio avec une solution de plus de 20 projets?

  • Et quelle est la stabilité du fichier de solution avec un développement simultané contrôlé par la source?


N'oubliez pas que les réponses peuvent être spécifiques à des versions particulières de Visual Studio.
stakx

Réponses:


21

Récemment, nous avons migré presque tout le code source de mon entreprise dans une seule solution.

Pourquoi?

À l'origine, nous avions des dizaines de solutions. Certains projets d'une solution réutilisaient des projets d'une autre, et personne ne se souciait d'utiliser un gestionnaire de packages. Le jour où vous changez substantiellement un projet qui est utilisé presque partout, attendez-vous à des heures et des heures de travail perdu pour toute l'entreprise pour les prochains jours ou semaines. Le pire, c'est que vous ne pouvez même pas savoir exactement ce qui serait affecté par le changement.

La fusion de tout le code en une seule solution était une alternative. Cela fonctionne bien pour le moment, et les dépendances sont désormais faciles à suivre. Vous souhaitez modifier une méthode mais également suivre les répercussions que ce changement peut avoir n'importe où dans la base de code? Visual Studio peut le faire facilement. Pour moi, c'est un succès.

L'intégration continue est désormais aussi plus facile. Une solution à compiler et à déployer. Presque rien à configurer.

Est-il évolutif?

Côté performances, j'ai été très surpris par Visual Studio . Je pensais qu'il va commencer à pleurer avec une solution avec, disons, 50 projets. Aujourd'hui, il y a plus de 200 projets; Visual Studio semblait être suffisamment évolutif pour les gérer comme s'il n'y en avait que 20. Oui, il y a des choses qui prennent du temps. Si vous recompilez chaque projet, avec les contrats de code, l'analyse de code activée par défaut, etc., attendez-vous à ce que cela prenne un certain temps. Mais personne ne s'attendrait à compiler 200 projets aussi rapidement que 10, et en passant, vous ne devriez pas: c'est le rôle du serveur d'intégration continue. Le temps de démarrage (démarrage à froid, puis chargement de la solution) est incroyablement rapide ; peut-être pas aussi vite qu'avec 10 projets, mais tout de même très acceptable (moins de 20 secondes sur une machine achetée il y a plus de cinq ans).

Pour aller encore plus loin, le déchargement systématique des projets est une bonne idée (et très simple lorsque les projets sont organisés dans des répertoires de la solution). Si quelqu'un travaille sur quelque chose qui ne nécessite que le chargement de trois projets, il n'est pas nécessaire de charger les 200 projets (sauf, bien sûr, les dépendances peuvent être affectées).

Le contrôle de version fonctionne également comme prévu (j'utilise un serveur SVN, si cela est important). Je n'ai pas travaillé dans un véritable environnement simultané, avec, par exemple, des dizaines de développeurs qui commettent fréquemment du code, mais j'imagine que cela n'aurait pas trop de problèmes. Attention aux cas où de nombreux développeurs ajoutent de nouveaux projets en même temps: la fusion du fichier .sln n'est pas la chose la plus simple à faire.

Conclusion

Si je devais choisir à nouveau la décision:

  1. Je migrerais toujours tout dans une seule solution. Cela réduit considérablement la douleur des dépendances brisées, et cet avantage à lui seul en vaut la peine. Avoir une place centralisée pour tout le code est également une bonne idée; cela permet, par exemple, de rechercher quelque chose dans Visual Studio. Je peux également travailler sur deux projets faiblement liés et avoir toujours une seule fenêtre Visual Studio ouverte.

  2. J'étudierais également un peu plus NuGet et la possibilité d'héberger un serveur NuGet privé. La gestion des dépendances via NuGet peut résoudre certains des problèmes lorsque vous ne souhaitez pas fusionner quelques projets dans la solution commune. Personnellement, je n'avais pas de tels cas, mais j'imagine que d'autres entreprises pourraient en avoir.

  3. Enfin, investir dans un SSD pour chaque développeur peut faire une énorme différence. Mais vous n'en avez pas besoin, et dans mon cas, la base de code est toujours stockée sur un disque dur ordinaire.


2
Juste quelques points FYI: Vous pouvez également ouvrir des projets via le fichier .csproj dans VS si la vitesse / les performances sont un problème. Un "serveur privé" NuGet n'est qu'un dossier réseau (et ajoutez ce dossier comme emplacement de source de package dans VS) - déposez simplement les fichiers nupkg là-bas et cela fonctionne.
Steven Evers

Merci, MainMa d'avoir partagé vos expériences avec une configuration de solution unique; une réponse très détaillée et utile. Une réserve que j'ai est d'avoir toutes les applications ensemble dans une seule solution, c'est de donner à un développeur junior l'accès à tout. Nous utilisons Ankhsvn et je préfère donner à un développeur junior l'URL d'une seule application sur laquelle je veux qu'il travaille plutôt que de lui donner accès à tout. Des réflexions à ce sujet?
BruceHill

@BruceHill: avec SVN, vous pouvez configurer précisément qui a accès à quoi. Le développeur junior pourra toujours voir tous les répertoires racine (voir ma question sur la défaillance du serveur ), mais ne pourra pas accéder aux projets restreints.
Arseni Mourzenko

2
Travaillant pour quelques grandes entreprises avec de grandes équipes de développeurs engageant quotidiennement du code, je peux vous dire que l'approche de solution unique ne fonctionne pas. Chaque projet est en surcharge. Chargement, construction et Dieu sait quelles étapes de pré / post-construction quelqu'un pourrait avoir attaché auxdits projets. Maintenant, avec une grande équipe de développeurs, vous aurez des changements dans plusieurs de ces projets chaque jour. Incluez des tests unitaires en cours d'exécution, etc. à chaque enregistrement pour une intégration continue et vous aurez encore plus de frais généraux. Avoir une solution unique par unité déployable (service, site Web) et utiliser un gestionnaire de packages comme NuGet.
Always Learning

8

Il s'agit de l'usage prévu.

Quels sont les avantages et les inconvénients de mettre toutes vos applications dans une seule solution plutôt que d'avoir des solutions distinctes pour chaque application?

  • avantages:
    • des références plus faciles entre les projets
    • débogage / étape plus facile
    • plus facile à attacher aux processus (c.-à-d. que vous passez par un service Windows, quand il passe au code de bibliothèque partagée, et cela fonctionne simplement parce que tous les symboles sont déjà chargés et pris en compte)
    • la recherche de code dans l'idé fonctionne mieux (vous n'avez pas nécessairement besoin de savoir dans quel projet réside le code que vous recherchez)
    • les listes de modifications inter-projets sont plus faciles à gérer (c'est-à-dire que vous avez modifié le code de la bibliothèque, vous devez donc mettre à jour le code client en même temps, avec 1 enregistrement)
  • les inconvénients:
    • vitesse de construction: si vous avez l'habitude de "tout reconstruire", les builds prennent plus de temps. Les builds beaucoup plus longs et incrémentiels ont parfois un comportement funky.
    • vitesse d'idée: voir ensuite

Quelle est la vitesse de Visual Studio avec une solution de plus de 20 projets?

Avec plus de 20 projets ... ce n'est peut-être pas si mal. J'en ai vu plus sans que VS n'ait de problèmes. C'est assez stable / rapide. CEPENDANT ... si c'est un problème, il peut être atténué: ouvrez le .csproj dans VS et travaillez à partir de là. Vous ne bénéficiez pas des avantages d'avoir tout dans une seule solution, mais vous pouvez toujours rouvrir le sln quand vous en avez besoin et travailler dans le .csproj quand vous en avez besoin (comme vous le faites maintenant).

Et quelle est la stabilité du fichier de solution avec un développement simultané contrôlé par la source?

Le fichier de solution ne change que lorsque vous ajoutez / supprimez des projets ou des objets au niveau de la solution, il change donc rarement. C'est du xml, donc vous pouvez voir ce qu'il contient. Ils changent rarement.


Steve, tu as dit "C'est l'usage prévu." Pouvez-vous fournir une référence pour cela? Merci!
reformé
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.