Monorepo avec C# : organisation du code en pratique

Monorepo avec C# : organisation du code en pratique

Dans le développement moderne en C# (.NET), la question du choix entre un monorepo et un multirepo se pose de plus en plus souvent. Un monorepo est une approche où tout le code de plusieurs projets, bibliothèques et services est stocké dans un seul dépôt Git. Dans cet article, nous allons voir comment organiser un monorepo pour des solutions C#, avec des exemples pratiques de structure, de configuration de build et de gestion des dépendances.

Avantages du monorepo pour C#

Le monorepo est particulièrement utile lorsque vous avez plusieurs projets liés : API web, applications console, bibliothèques de classes et tests. Les principaux avantages :

\n
• Version unique des dépendances — tous les projets utilisent la même version des packages NuGet et des bibliothèques internes.
\n
• Refactoring simplifié — une modification de l'API dans une bibliothèque est immédiatement visible chez tous les consommateurs.
\n
• CI/CD centralisé — un seul pipeline pour la build, les tests et le déploiement de tous les composants.
\n
• Réduction des duplications — les modèles communs, utilitaires et configurations sont extraits dans des projets partagés.
\n

Cependant, il faut aussi tenir compte des inconvénients : augmentation de la taille du dépôt, allongement du temps de clonage (si l'on n'utilise pas le sparse checkout), et nécessité d'un système de droits d'accès bien pensé.

Structure d'un monorepo en C#

Examinons une structure typique de monorepo pour un projet .NET. Supposons que nous ayons des microservices AuthService, OrderService et une bibliothèque commune Shared.

MyMonorepo/\n├── .github/\n│   └── workflows/\n│       └── ci.yml\n├── src/\n│   ├── AuthService/\n│   │   ├── AuthService.Api/\n│   │   │   ├── Controllers/\n│   │   │   ├── Program.cs\n│   │   │   └── AuthService.Api.csproj\n│   │   └── AuthService.Tests/\n│   │       └── AuthService.Tests.csproj\n│   ├── OrderService/\n│   │   ├── OrderService.Api/\n│   │   │   └── OrderService.Api.csproj\n│   │   └── OrderService.Tests/\n│   │       └── OrderService.Tests.csproj\n│   └── Shared/\n│       ├── Shared.Models/\n│       │   └── Shared.Models.csproj\n│       └── Shared.Utils/\n│           └── Shared.Utils.csproj\n├── tests/\n│   └── IntegrationTests/\n│       └── IntegrationTests.csproj\n├── MyMonorepo.sln\n├── Directory.Build.props\n├── Directory.Packages.props\n├── .gitignore\n└── README.md

Éléments clés :

\n
• src/ — dossier principal contenant le code source.
\n
• tests/ — tests d'intégration, s'ils ne sont pas liés à un service spécifique.
\n
• Directory.Build.props — paramètres MSBuild communs pour tous les projets.
\n
• Directory.Packages.props — gestion centralisée des versions des packages NuGet (mode Central Package Management).
\n
• .sln — fichier de solution qui regroupe tous les projets.
\n

Configuration de la gestion centralisée des dépendances

Dans .NET 6+, la prise en charge intégrée de Central Package Management (CPM) est apparue. C'est parfait pour un monorepo. Créez un fichier Directory.Packages.props à la racine :

<Project>\n  <PropertyGroup>\n    <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>\n  </PropertyGroup>\n  <ItemGroup>\n    <PackageVersion Include="Microsoft.AspNetCore.App" Version="8.0.0" />\n    <PackageVersion Include="Microsoft.EntityFrameworkCore" Version="8.0.0" />\n    <PackageVersion Include="xunit" Version="2.7.0" />\n  </ItemGroup>\n</Project>

Maintenant, dans chaque .csproj, il suffit d'indiquer uniquement le nom du package sans la version :

<Project Sdk="Microsoft.NET.Sdk.Web">\n  <PropertyGroup>\n    <TargetFramework>n