Une CLI .NET durable commence par une grammaire prévisible : commandes organisées par domaine, options cohérentes, aide utile et erreurs adaptées aux scripts. System.CommandLine fournit des outils pour l’analyse, l’aide et la complétion; le Generic Host et Native AOT sont des choix d’architecture et de publication à justifier selon les besoins, pas des étapes obligatoires.
Pourquoi la syntaxe de votre CLI est un contrat
Les utilisateurs peuvent intégrer commandes et options à des scripts, des tâches planifiées ou des chaînes de déploiement. Une modification apparemment mineure peut donc casser des automatisations existantes. Microsoft résume ce risque ainsi : “Once you create a CLI, it is hard to change, especially if your users have used your CLI in scripts they expect to keep running.”
As an Amazon Associate I earn from qualifying purchases.
Concevez la grammaire avant de multiplier les commandes : choisissez les noms, les valeurs par défaut, les règles de validation et les codes de sortie, puis documentez-les. La guidance de conception de Microsoft recommande de regrouper les sous-commandes par domaine et de nommer les actions avec des verbes.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitchesDes commandes et options faciles à anticiper
Une forme telle que outil projet créer sépare le domaine de l’action. Préférez des noms courts, cohérents, en minuscules et en kebab-case. Réservez les options aux paramètres plutôt qu’à des actions cachées : --output indique où écrire, tandis qu’une action distincte devrait exprimer ce que l’outil fait.
#1 Best Overall
Respectez les attentes familières pour les options courantes : -i ou --interactive signale que l’outil peut demander des informations, -o ou --output désigne généralement une sortie, et -v ou --verbosity règle le niveau de détail. Si le mode interactif peut bloquer, rendez ce comportement explicite afin qu’un script non interactif ne se retrouve pas à attendre une réponse.
Les conventions du .NET CLI ne coïncident pas nécessairement avec celles de POSIX. Indiquez clairement les comportements retenus et évitez de supposer qu’un shell ou un programme hôte interprétera les arguments comme votre application.
Quand System.CommandLine est utile
System.CommandLine est la bibliothèque Microsoft destinée à analyser les arguments et à afficher l’aide. Sa documentation décrit la prise en charge des conventions POSIX et Windows, de la complétion par tabulation et des fichiers de réponse; elle indique aussi une compatibilité avec le trimming et les applications AOT. Ces capacités peuvent éviter de réimplémenter des comportements de parsing usuels.
Le tutoriel Microsoft commence par un RootCommand et une option typée, puis parse les arguments avant d’en lire la valeur. Il souligne un détail important : si l’action racine ne traite pas le cas où aucune option n’est fournie, l’aide n’apparaît pas automatiquement dans cet exemple initial. Une fois une action ajoutée, RootCommand fournit par défaut --help, --version et la directive de suggestion. Ce tutoriel illustre les mécanismes; il ne constitue pas un benchmark ni une preuve de performance en production.
Décider selon les besoins de l’outil
- Pour une CLI à quelques arguments simples, une analyse directe peut suffire si les règles restent compréhensibles et testables.
- Pour une interface avec plusieurs commandes, options, aide, alias ou cas de parsing, System.CommandLine apporte une structure et des fonctionnalités documentées.
- Si vous ciblez le trimming ou Native AOT, vérifiez la compatibilité de toute la chaîne de dépendances plutôt que de vous fier à la seule compatibilité annoncée de la bibliothèque.
La vue d’ensemble de la syntaxe couvre notamment la position des options avant ou après les arguments, les alias, les booléens, l’arité, les fichiers de réponse et le séparateur --. Ce dernier est utile quand un outil doit transmettre des arguments à un programme lancé. Par exemple, dotnet run transmet à l’application les tokens placés après --. Définissez et documentez les cas limites propres à votre outil.
Traiter erreurs, sorties et codes de retour comme une API
Une CLI sert à la fois des personnes et des scripts. Séparez donc le contenu attendu des diagnostics : écrivez les erreurs sur stderr pour qu’elles ne se mélangent pas à une sortie redirigée sur stdout. Définissez les arguments requis, les valeurs par défaut, les validations et des messages qui indiquent comment corriger l’appel.
Documentez les codes de sortie et attribuez-leur une signification stable. Le tutoriel System.CommandLine de Microsoft montre une erreur de parsing qui affiche l’erreur et l’aide, puis renvoie le code 1; il montre aussi qu’une action peut renvoyer un entier. Ce sont des exemples de mécanismes, pas une convention universelle pour les erreurs métier. Choisissez vos propres codes selon les usages attendus et gardez leur signification cohérente.
Tester le contrat, pas seulement le code métier
La documentation de System.CommandLine relève qu’il est possible de tester l’application indépendamment de l’analyse des arguments. Gardez les actions métier séparées du parsing autant que l’architecture le permet : cela facilite les tests unitaires sans devoir simuler une invocation complète.
Ajoutez aussi des tests d’intégration qui invoquent réellement la CLI et vérifient les arguments acceptés, le texte produit sur stdout et stderr, ainsi que les codes de sortie. Les tests doivent refléter le contrat que vous voulez maintenir, notamment pour l’aide, les entrées invalides et les cas non interactifs.
Ajouter le Generic Host et l’injection de dépendances seulement si nécessaire
Une petite application console peut rester une application console simple. Quand la configuration, la durée de vie des services ou la composition des composants deviennent plus complexes, le Generic Host et IServiceCollection offrent une voie .NET documentée pour enregistrer les services et construire un fournisseur via IHost.
Le tutoriel Microsoft sur l’injection de dépendances illustre cette approche dans une application console avec un exemple ciblant .NET 10. Cela confirme que DI est disponible; cela ne la rend pas nécessaire pour chaque CLI. Évaluez le coût de configuration, les dépendances et la clarté obtenue avant d’ajouter cette couche.
Choisir Native AOT selon les contraintes de distribution
Native AOT produit une application autonome compilée en code natif, sans compilation JIT à l’exécution. Microsoft associe à cette approche un démarrage plus rapide, une empreinte mémoire plus réduite et la possibilité d’exécuter l’application sur une machine dépourvue du runtime .NET. Ces bénéfices généraux ne donnent pas de chiffres de performance applicables à une CLI particulière.
Best Value
La publication AOT est liée au système d’exploitation et à l’architecture ciblés. Elle peut aussi exiger des toolchains et dépendances natives, tandis que certaines bibliothèques ne sont pas compatibles avec toutes les contraintes AOT. Avant de retenir cette voie, vérifiez les dépendances et utilisez les analyseurs de compatibilité recommandés par Microsoft dans la documentation Native AOT. Testez les artefacts sur les plateformes réellement distribuées.
Une décision fondée sur le contexte de livraison
- Restez sur une publication .NET classique si la simplicité de construction et une large compatibilité avec les bibliothèques priment.
- Envisagez Native AOT si l’exécution sans runtime installé et les caractéristiques de démarrage ou d’empreinte répondent à un besoin concret.
- Dans les deux cas, testez le processus de publication et l’exécutable final pour chaque combinaison de système et d’architecture prise en charge.
Une démarche de conception pragmatique
- Écrivez les commandes et options que les utilisateurs devront pouvoir automatiser; regroupez les actions par domaine et choisissez des noms cohérents.
- Précisez les valeurs par défaut, les validations, le comportement interactif, les flux stdout/stderr et les codes de sortie.
- Choisissez un parseur en fonction de la complexité réelle. Si vous adoptez System.CommandLine, vérifiez les comportements d’aide, d’erreur et de transmission d’arguments utiles à votre outil.
- Séparez autant que possible l’action métier de l’analyse des arguments, puis testez chaque couche et les invocations de bout en bout.
- Ajoutez Generic Host/DI ou Native AOT uniquement lorsque leurs avantages répondent à des besoins identifiés, en vérifiant leurs coûts et contraintes.
Pour situer la CLI dans l’écosystème, la documentation du .NET CLI décrit les outils de ligne de commande du SDK. Votre propre application peut adopter des conventions familières sans prétendre reproduire exactement celles du SDK.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
