Introduction

Lors des différentes missions sur lesquelles je suis intervenu, je me suis vite rendu compte que l’architecture d’une solution est souvent la même :

• Server
  • Socity.Project.Core
  • Socity.Project.Infrastructure
  • Socity.Project.API
• Client

On peut retrouver un schéma qui résume bien cette architecture sur la documentation Microsoft.

Visual Studio permet de créer des modèles de solution pour une architecture donnée. Quels en sont les avantages et inconvénients ?

Avantages

1. Le gain de temps : pas besoin d’imaginer une nouvelle architecture de zéro lorsque l’on commence un nouveau projet dans la mesure où le travail est presque toujours le même.
2. Une structure stable : démarrer à partir d’une base approuvée permet tout de suite de se projeter sur l’emplacement de chaque élément dont on aura besoin.
3. Facilité : cela permet aux personnes moins expérimentées de s’appuyer sur le socle.
4. Les dépendances : lors de la création du modèle on peut donner les dépendances minimums à intégrer. Que ce soit l’interconnexion entre les projets ou les dépendances externes, chaque projet aura besoin d’intégrer ses « Packages Nuget ».

Inconvénients

1. Manque de souplesse : dans certains cas, les projets plus ou moins complexes peuvent nécessiter une refonte de l’architecture au début du projet, utiliser un modèle figé n’est alors pas toujours adapté
2. Le partage : faire un modèle c’est bien, mais il est nécessaire de le partager entre plusieurs développeurs d’une organisation. Il est possible de modifier le répertoire utilisé par Visual Studio pour trouver les modèles (voir plus loin) pour utiliser un répertoire partagé, mais cela implique d’une part une maintenance supplémentaire du contenu de ce répertoire pour aussi mettre à jour les modèles de Microsoft en cas de mises à jour. Il est également possible de créer une extension Visual Studio qui mettra à jour ce modèle dans le répertoire par défaut des modèles, mais dans ce cas il faut maintenir à jour cette extension en plus du modèle lui-même et la mettre à disposition des développeurs via un site web ( flux ATOM ou bibliothèque de documents SharePoint) déclaré comme une galerie privée d’extensions (voir : Galeries privées – Visual Studio | Microsoft Docs). Dans les 2 cas il faut modifier la configuration Visual Studio de chaque développeur pour celà.

Conception du modèle

Dans ce chapitre nous allons voir comment créer notre premier modèle de solution et l’enrichir au fur et à mesure pour que nous puissions le réutiliser.

On va créer ensemble une architecture de type Onion Architecture pour une Web API, pour ne l’implémenter qu’une seule fois et pouvoir l’utiliser directement lors de nos nouveaux projets.

Création d’une solution et des projets

A la base nous devons créer une solution pour contenir tous nos projets.

Ouvrez Visual Studio puis la page d’accueil sélectionnée : « Créer un projet »

Dans notre cas nous sélectionnons : « API web ASP.NET Core »

A droite nous retrouvons dans notre « Explorateur de solutions » le nom de solution ainsi qu’à l’intérieur notre projet API.

Ajoutons nos deux autres projets (Core & Infrastructure) : « Bibliothèque de classes »

Pour une meilleure structuration, j’ai l’habitude de créer des répertoires de solution pour distinguer plus facilement mes projets. Voici le résultat final de ma solution:

Nota : le projet Front est présent juste ici comme exemple et ne fera pas partie du modèle.

Ajoutez les relations suivantes entre les projets :

• Softluent.Template.Infrastructure ->Softluent.Template.Core
• Softfluent.Template.API ->Softluent.Template.Core + Softluent.Template.Infrastructure

Mettez en place les différents « Pakages Nuget » dont vous aurez besoin pour le bon fonctionnement de vos projets.

Création du modèle

Nous devons commencer par faire un export de chaque projet. Pour cela rendez-vous dans « Projet » → « Exporter le modèle… »

Choisissez le projet que vous souhaitez exporter.

Décochez la case « Importer automatiquement le modèle dans Visual Studio » pour ne pas avoir le projet comme modèle.

Maintenant nous avons trois projets compressés. (Regardez l’emplacement de sortie choisie pour les retrouver)

Faites l’extraction de chaque archive dans un dossier distinct. Utilisez $safeprojectname$ pour changer dynamiquement les noms de projets

Et si vous souhaitez utiliser le nom de la solution ajoutée « _ext » pour récupérer une variable du parent par exemple $ext_safeprojectname$ (pratique pour les références entre projets)

Ajoutez une icône et un fichier vstemplate à la racine de votre dossier.

Modifiez le fichier « Solution.vstemplate » pour définir les différents paramètres

Voici le résultat de nos sous-dossiers avec les modifications :

Si nous laissons tel quel, nous obtiendrons le résultat suivant :

Certes cela peut suffire mais il est utile d’ajouter des tags qui permettent d’utiliser les filtres lors de la création du projet. Cela nous évite de rechercher uniquement via le nom.
Pour ce faire : éditez le fichier « Solution.vstemplate » et ajoutez dans la section « TemplateData » les tags dont vous avez besoin.
Par exemple :

De la même manière, si vous souhaitez comme moi créer un dossier de solution pour regrouper vos projets, ajoutez dans « ProjectCollection » une balise « SolutionFolder »

Utilisation du modèle

Nos sources sont maintenant terminées et nous voulons créer notre modèle pour pouvoir créer rapidement nos nouveaux projets.
Sélectionnez l’ensemble des éléments à partir de la solution et ajoutez à l’archive.

Déplacer votre archive dans votre dossier de ressources Visual Studio

\\Documents\Visual Studio XXXX\Templates\ProjectTemplates

Maintenant si vous ouvrez Visual Studio et que vous créez un nouveau projet votre modèle de solution personnalisé apparaît.

Renseignez le nom de votre projet et celui de votre solution.

Vérifiez que les noms renseignés sont bien pris en compte.

Lancez une génération pour voir s’il y a eu un problème lors de la compilation de votre solution. (Raccourci : ctrl + lshift + b)

Conclusion

Appréhender le système de modèle de solutions prend un peu de temps, mais une fois que l’on a compris le fonctionnement, on peut créer un modèle pour chaque structure courante et gagner du temps sur le long terme.

Merci d’avoir lu cet article jusqu’au bout, vous trouverez les sources qui m’ont permis d’écrire cet article ci-dessous ainsi que les ressources.

Sources

• https://docs.microsoft.com/fr-fr/visualstudio/ide/creating-solutions-and-projects
• https://docs.microsoft.com/fr-fr/visualstudio/ide/creating-project-and-item-templates?view=vs-2019
• https://devblogs.microsoft.com/visualstudio/build-visual-studio-templates-with-tags-for-efficient-user-search-and-grouping/
• https://docs.microsoft.com/fr-fr/visualstudio/extensibility/projecttemplatelink-element-visual-studio-templates?view=vs-2019
• https://docs.microsoft.com/fr-fr/visualstudio/extensibility/solutionfolder-element-visual-studio-templates?view=vs-2019
• https://docs.microsoft.com/en-us/visualstudio/ide/template-parameters?view=vs-2019
• https://docs.microsoft.com/fr-fr/visualstudio/ide/how-to-create-multi-project-templates?view=vs-2019
• https://docs.microsoft.com/fr-fr/visualstudio/extensibility/private-galleries?view=vs-2019
• https://docs.microsoft.com/fr-fr/dotnet/architecture/modern-web-apps-azure/common-web-application-architectures

Annexe

Les sources de l’exemple sont disponibles ici :

• https://github.com/lpcd/vs-solution-template