Workflow de compilation et de test du dépôt dotnet/runtime
.NET est un environnement d'exécution multiplateforme pour les applications cloud, mobiles, de bureau et IoT.
En bref
- De quoi s’agit-il ?
- Un guide basé sur la documentation du workflow du dépôt : plateformes de compilation, configurations, composants, scripts, tests et triage CI.
- À qui s’adresse-t-il ?
- La documentation du workflow renvoie aussi à des ressources sur les performances et le triage CI, mais ne contient pas de commandes d'installation ni d'historique de versions.
- Puis-je l’utiliser commercialement ?
- Oui. MIT est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Le dépôt a reçu de nouveaux commits au cours des dernières 24 heures.
- En quel langage est-il écrit ?
- Principalement C#, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le guide de workflow commence par les plateformes
Le dépôt dotnet/runtime documente son workflow de compilation et de test dans docs/workflow/README.md. Le dépôt est écrit en C# et décrit comme un runtime multiplateforme pour applications cloud, mobiles, de bureau et IoT. Le guide explique que le dépôt peut être utilisé sur Windows, Linux, macOS et FreeBSD, mais que toutes les architectures ne sont pas prises en charge pour le développement. Les builds peuvent cibler un plus large éventail de plateformes que celles utilisées pour le développement. Le guide commence donc par distinguer la plateforme de build, où les outils de compilation s'exécutent, de la plateforme cible, où les artefacts compilés s'exécutent.
Plateformes de build prises en charge et cross-compilation
Le guide inclut une matrice des combinaisons de plateformes de build prises en charge. Sur x64, Windows, Linux, macOS et FreeBSD sont pris en charge ; x86 uniquement sur Windows ; Arm32 uniquement sur Linux ; et Arm64 sur Windows, Linux et macOS. Chaque système d'exploitation a un document d'exigences lié. Lorsque la plateforme de build et la plateforme cible diffèrent, le processus est appelé cross-compilation. Certains workflows, comme WebAssembly, les navigateurs et les cibles mobiles, nécessitent une cross-compilation car le dépôt ne peut pas être compilé directement sur ces plateformes.
Taille du dépôt et composants principaux
Le guide donne des chiffres concrets : cloner l'historique complet nécessite environ 400 à 500 Mo de transfert réseau et peut consommer 1 à 1,5 Go en local. Une compilation peut prendre 10 à 20 Go d'espace pour une seule configuration de système et de plateforme, selon les parties du produit compilées. Le dépôt se compose de trois composants majeurs : les runtimes (CoreCLR et Mono), les bibliothèques, et les hôtes et installateurs. Les builds peuvent être lancés depuis un terminal ordinaire à la racine du dépôt, sans sudo ni privilèges administrateur.
Trois configurations de build
Le guide définit trois configurations de build prises en charge. Debug utilise du code non optimisé avec des assertions activées, s'exécute le plus lentement et offre la meilleure expérience de débogage. Checked est exclusive au runtime CoreCLR et utilise du code optimisé tout en gardant les assertions activées. Release utilise du code optimisé avec des assertions désactivées, s'exécute à la meilleure vitesse et convient le mieux au profilage des performances, mais les optimisations du compilateur rendent le débogage plus difficile.
Runtimes, CoreLib et bibliothèques
Le guide décrit les principaux composants de build. Le runtime est le moteur d'exécution du code managé, avec deux implémentations écrites en C ou C++ : CoreCLR, un moteur complet issu de .NET Framework, et Mono, un runtime plus léger né en open source pour apporter .NET et C# aux plateformes non Windows. CoreLib, aussi appelé System.Private.CoreLib, est la bibliothèque managée de plus bas niveau et doit être compilée dans la même configuration que le runtime. Les bibliothèques fournissent le reste des fonctionnalités et peuvent être compilées dans une configuration indépendante du runtime.
build.sh et sous-ensembles
Le script de build principal est build.sh, ou build.cmd sous Windows, à la racine du dépôt. Il accepte des sous-ensembles pour compiler des composants spécifiques. Les principales valeurs de sous-ensemble sont Clr (le runtime CoreCLR complet plus CoreLib), Libs (tous les composants de bibliothèques sans les tests), Packs (packs de framework partagé et installateurs), Host (hôtes .NET et bibliothèques d'hébergement) et Mono (le runtime Mono et son CoreLib). Plusieurs sous-ensembles peuvent être compilés ensemble en les reliant par un signe plus, par exemple ./build.sh -subset clr+libs -configuration Release.
Tests, avertissements et triage CI
Le dépôt comprend des suites de tests pour chaque composant, avec des liens vers la documentation de test pour CoreCLR, NativeAOT, les bibliothèques et Mono. Pour le travail sur les performances, le guide renvoie aux workflows de benchmarking et de profilage du dépôt dotnet/performance. La compilation traite les avertissements comme des erreurs, y compris les avertissements de style de code. Cela peut être désactivé en définissant la variable d'environnement TreatWarningsAsErrors sur false avant la compilation. Il y a aussi des liens pour soumettre une PR et pour trier les échecs CI, où les tests flaky sont attendus dans une certaine mesure.
Conclusion éditoriale
La documentation du workflow renvoie aussi à des ressources sur les performances et le triage CI, mais ne contient pas de commandes d'installation ni d'historique de versions.
Notes de la communauté