5 commandes essentielles de .NET CLI que chaque développeur doit connaître
La plupart des développeurs C# passent leur flux de travail entier dans un IDE, en cliquant sur des boutons pour compiler, lancer, et tester leurs applications. Cela fonctionne jusqu'à ce que cela ne fonctionne plus. Les pipelines d'automatisation, les serveurs distants, et les environnements conteneurisés n'ont pas d'interface graphique, et connaître quelques commandes de terminal vous maintient productif dans ces situations sans avoir recours à une souris.
Dans sa vidéo "5 commandes CLI .NET essentielles que chaque développeur devrait connaître", Tim Corey parcourt les cinq opérations dotnet qui couvrent le plus de terrain dans le développement quotidien : build, run, watch, clean, et publish. Chacune obtient une démonstration pratique, montrant non seulement la syntaxe mais aussi quand et pourquoi vous la choisiriez. Que vous soyez à l'aise avec le terminal ou que vous l'ouvriez rarement, celles-ci valent la peine d'être retenues.
Vérification de votre environnement avec dotnet --info
[0:31 - 1:25] Avant de lancer des commandes de projet, Tim commence par vérifier l'environnement de développement. La commande dotnet à elle seule confirme que le CLI est installé et accessible dans votre chemin, mais dotnet --info va plus loin :
dotnet --info
dotnet --info
Ceci affiche chaque version SDK et runtime installée sur votre machine, ainsi que les détails du système d'exploitation et de l'architecture active. Tim démontre cela sur .NET 10, mais la commande fonctionne de manière identique sur n'importe quelle version. Savoir ce que vous avez installé est particulièrement utile lors du débogage des incompatibilités de version ou pour vérifier qu'un serveur CI reflète votre configuration locale.
Commande 1 : dotnet build
[2:16 - 3:44] La première commande compile votre projet sans le lancer :
dotnet build
dotnet build
Exécuter ceci depuis le répertoire du projet lit le fichier .csproj, résout les dépendances, et produit une sortie compilée sous le dossier bin. Tim souligne que la compilation est une étape distincte, séparée de l'exécution. Cette séparation est importante lorsque vous souhaitez vérifier que votre code compile correctement avant de le pousser à un référentiel ou de le transmettre à un serveur de construction.
Le .NET SDK gère la résolution des dépendances pendant le processus de construction, tirant tout paquetage NuGet manquant et assurant que toutes les bibliothèques référencées sont présentes. Si quelque chose échoue à ce stade, les messages d'erreur pointent directement vers le problème, qu'il s'agisse d'une référence manquante, d'une erreur de syntaxe ou d'une incompatibilité de cadre cible. Éviter ces problèmes avant de lancer l'application économise du temps dans le cycle de développement global.
Commande 2 : dotnet run
[3:44 - 5:42] Là où build s'arrête à la compilation, run prend l'étape suivante et lance l'application :
dotnet run
dotnet run
Cela compile le projet (si nécessaire) puis exécute la sortie résultante. Pour une application console, cela signifie l'exécuter dans le terminal. Pour un projet web, le serveur intégré Kestrel démarre et l'application devient disponible à une URL locale.
Tim démontre cela avec une application web, naviguant jusqu'au site en cours d'exécution dans un navigateur pour confirmer que tout se charge correctement. La distinction clé entre build et run est que run produit un résultat interactif en direct. Pendant le développement actif, c'est la commande que vous utiliserez le plus fréquemment pour tester les modifications et voir leur effet.
Commande 3 : dotnet watch
[5:42 - 7:06] Arrêter l'application, faire une modification, et la redémarrer devient vite fastidieux. La commande watch élimine ce cycle :
dotnet watch
dotnet watch
Cela entoure le processus d'exécution dans un observateur de fichiers. Lorsque vous enregistrez une modification dans n'importe quel fichier source, la CLI détecte la modification et recompile et actualise automatiquement l'application. Pour les applications web construites avec ASP.NET Core, les modifications aux fichiers Razor, CSS, et au code C# apparaissent dans le navigateur sans redémarrage manuel.
Tim montre le comportement de rechargement à chaud en action : en éditant une page, en enregistrant, et en voyant la mise à jour se refléter immédiatement. Ce cycle de rétroaction serré est précieux pendant le travail sur l'UI, où des ajustements mineurs surviennent constamment. Au lieu de passer par le cycle arrêter-modifier-reconstruire-lancer, vous restez concentré sur le code et laissez l'outillage gérer le reste.
Commande 4 : dotnet clean
[7:06 - 7:56] Les artefacts de construction s'accumulent dans les répertoires bin et obj au fil du temps. Occasionnellement, des fichiers compilés obsolètes engendrent un comportement déroutant où vos derniers changements de code ne semblent pas prendre effet, ou où une construction réussit localement mais échoue sur une nouvelle machine. La commande clean aborde cela :
dotnet clean
dotnet clean
L'exécution de cela supprime le contenu des répertoires de sortie pour que votre construction suivante commence à zéro. Tim présente cela comme un outil de dépannage plutôt que quelque chose que vous exécutez après chaque modification. Lorsque votre projet se comporte de manière inattendue et que vous soupçonnez que la sortie mise en cache est le coupable, clean suivi de build assure que vous travaillez avec une compilation vraiment fraîche.
Cette habitude est particulièrement utile en cas de changement de branches dans le contrôle de version, de mise à niveau d'une dépendance vers une nouvelle version majeure, ou de résolution d'avertissements de compilation intermittents qui semblent apparaître et disparaître sans cause claire.
Commande 5 : dotnet publish
[7:56 - 9:01] La commande finale fait le lien entre le développement et le déploiement :
dotnet publish
dotnet publish
Tandis que build produit une sortie adaptée au débogage local, publish crée un paquet prêt pour le déploiement. Les assemblages compilés, les fichiers de configuration, les actifs statiques et tous les composants d'exécution requis se retrouvent dans un dossier publish que vous pouvez copier directement sur un serveur.
La distinction entre build et publish surprend certains développeurs. La sortie de build inclut des symboles de débogage et des références qui sont utiles pendant le développement mais inutiles (et parfois indésirables) en production. La publication retire ces extras et organise la sortie pour son environnement cible. Lors du déploiement sur Docker ou du téléchargement vers un hôte cloud, la sortie publiée est ce qui appartient à votre image finale ou paquet de version.
Conclusion : Cinq commandes, un flux de travail
[9:01 - 9:15] Tim termine en listant les cinq ensemble : dotnet build, dotnet run, dotnet watch, dotnet clean, et dotnet publish. Pris comme un ensemble, elles couvrent la boucle de développement de base de la compilation au déploiement. Chacune a un objectif spécifique, et savoir quand utiliser chacune vous donne un niveau de contrôle que cliquer sur les boutons de l'IDE seul n'offre pas.
Conclusion
[9:15 - 9:30] Ces cinq commandes CLI gèrent les tâches que vous effectuez le plus souvent pendant le développement : compilation, exécution, rechargement en direct, suppression de sorties obsolètes, et empaquetage pour la sortie. Elles fonctionnent sur chaque type de projet .NET et chaque système d'exploitation pris en charge par le SDK.
La prochaine fois que vous ouvrez un terminal, que ce soit sur votre machine locale, à l'intérieur d'un conteneur, ou sur un serveur distant, vous avez déjà le vocabulaire pour progresser dans le cycle de développement complet sans interface graphique.
Exemple de conseil : Vous pouvez enchaîner clean et build en une seule ligne avec dotnet clean && dotnet build. Cela garantit une compilation à partir de zéro en une seule étape, ce qui est particulièrement pratique lors du dépannage des problèmes qui persistent à travers les constructions incrémentielles.
Regardez la vidéo complète sur sa chaîne YouTube et obtenez plus d'aperçus sur les bases essentielles de .NET CLI.
