Comment structurer plusieurs solutions / projets qui se chevauchent dans .Net?

J'ai récemment commencé à travailler pour un nouveau client avec une ancienne base de code héritée dans laquelle il existe plusieurs solutions .net, chacune héberge généralement certains projets uniques à cette solution, mais "emprunte" / "relie" (ajouter un projet existant) quelques autres projets qui appartient techniquement à d'autres solutions (du moins si vous passez par la structure des dossiers dans TFS)

Je n'ai jamais vu une configuration aussi entrelacée, il n'y a pas d'ordre de construction clair, parfois un projet dans la solution A référence simplement les DLL directement depuis le répertoire de sortie d'un projet hébergé dans la solution B, parfois le projet vient d'être inclus directement même s'il réside LOIN loin dans la structure des dossiers.

Il semble que tout a été optimisé pour la paresse des développeurs.

Quand je leur ai expliqué pourquoi ils n'avaient pas de serveur CI, ils ont répondu qu'il était difficile de configurer le code tel qu'il est. (Je l'installe maintenant et maudis cette organisation de code)

Les solutions sont organisées autour d'artefacts de déploiement (les choses qui doivent être déployées ensemble sont dans la même solution), ce qui, je pense, est une sage décision, mais le contenu de ces solutions (les projets) est partout.

Existe-t-il un consensus sur les meilleures pratiques à utiliser lors de la réutilisation de bibliothèques de classes communes sur plusieurs solutions / artefacts de déploiement,

• Comment structurer le code dans le VCS
• Comment faciliter le partage de la logique métier entre des artefacts de déploiement distincts

Je n'ai jamais été fan de l'inclusion de projets existants qui appartiennent à d'autres solutions. Il y a trop de variables où la modification de ce projet pour 1 solution casse complètement quelque chose dans une autre solution. Ensuite, en résolvant ce problème, vous finissez par casser la solution d'origine. Faire mousser, rincer, répéter.

Lorsque ce type de dépendance s'infiltre dans plusieurs solutions, j'aime séparer le code dépendant dans sa solution OWN et créer une bibliothèque de boîte noire qui est ensuite incluse comme référence. Je pense que vos solutions étaient intimement liées afin que le débogage puisse se faire tout au long du projet partagé pour chaque solution. Si la bibliothèque est construite et testée correctement, ce type de débogage n'est vraiment pas nécessaire. La bibliothèque doit être capable de se tenir sur ses propres mérites et doit être testée de manière approfondie afin que les attentes de tout projet de consommation soient satisfaites de manière cohérente.

J'ai en fait organisé de telles structures TFS comme celle que vous mentionnez et bien qu'elle présente des défis uniques pour CI, elle présente un certain nombre d'avantages différents. Il est clair qu'il prend en charge et encourage une bonne composanteisation dans des projets .NET séparés et prend donc en charge un bon TDD en encourageant une couverture de test à 100%. Dès le départ, je remarque quelques problèmes que vous pouvez résoudre.

parfois un projet dans la solution A référence simplement les DLL directement à partir du répertoire de sortie d'un projet hébergé dans la solution B, parfois le projet vient juste d'être inclus directement même s'il réside loin dans la structure des dossiers.

Les références binaires à la sortie d'autres répertoires ne sont pas une bonne approche et deviennent également une mauvaise approche lorsqu'elles sont mélangées avec des références de projet. Essayez de faire l'un ou l'autre, en changeant de préférence vos références binaires en références de projet pour plus de cohérence. À ce stade, chaque solution peut représenter une seule application ou niveau d'application à construire (par exemple, SuperApp.sln, OtherAppServices.sln, OtherAppPresentationTier.sln).

Pour créer TOUS les projets, je recommande également de créer une solution principale. La solution principale aura des références de projet à tout et existe essentiellement pour le seul avantage d'avoir une seule commande de génération qui gère tous les projets de la suite d'applications. Les développeurs ne doivent pas utiliser la solution principale pour le développement actif ou le débogage. Cela rend l'assemblage des artefacts de construction beaucoup plus facile.

Le déploiement peut alors être effectué avec un simple script batch, PowerShell ou Perl. Cela créera essentiellement la solution appropriée ou la solution principale, puis déploiera tout dans les environnements appropriés. Cela peut être facilement intégré dans n'importe quel serveur CI si cela est fait correctement.

• Comment faciliter le partage de la logique métier entre des artefacts de déploiement distincts

Créez un projet pour une logique métier commune ou ayez une meilleure séparation des préoccupations pour une logique métier plus globale ou universelle. Toutes les solutions déployables qui souhaitent y faire référence doivent le faire par une référence de projet.

En organisant votre code dans TFS, il devient plus facile d'y parvenir en gardant les projets communs ou partagés à un niveau supérieur dans l'arborescence de répertoires.