Exécution de fichiers C# basée sur des fichiers dans .NET 10

Exécution d'un fichier C# unique

[0:40 - 1:48] Tim démarre dans VS Code avec un dossier vide. Aucune solution, aucun fichier de projet, aucun modèle. Il crée un seul fichier appelé demo.cs avec une seule ligne de code :

Console.WriteLine("Hello World");

Console.WriteLine("Hello World");

Pour l'exécuter :

dotnet run file demo.cs

dotnet run file demo.cs

C'est le flux de travail complet. La commande dotnet run file compile et exécute le fichier .cs en une seule étape. Aucun .csproj intermédiaire n'est généré, aucun dossier bin ou obj créé. Le modèle mental est plus proche de la script que du développement C# traditionnel : écrivez un fichier, exécutez-le, voyez le résultat.

Tim fait une comparaison directe avec Python et JavaScript, où l'exécution de fichiers uniques a toujours été la norme. .NET 10 amène C# dans ce même territoire tout en gardant la sécurité des types et les performances qui rendent C# attrayant au premier abord.

Arguments en ligne de commande et Usings implicites

[1:48 - 3:26] Le tableau args est disponible automatiquement, tout comme il le serait dans un Program.cs standard avec des déclarations de haut niveau. Tim modifie le fichier pour accepter un argument de nom :

Console.WriteLine($"Hello {args[0]}");

Console.WriteLine($"Hello {args[0]}");

Exécution avec un argument :

dotnet run file demo.cs Tim

dotnet run file demo.cs Tim

Cela imprime "Hello Tim". Tim souligne que Console.WriteLine fonctionne sans une déclaration using System; car l'exécution basée sur des fichiers inclut par défaut des usings implicites. C'est le même comportement que les instructions de niveau supérieur ont introduit dans C# 9, maintenant étendu aux fichiers autonomes.

Le modèle plus large que Microsoft suit consiste à réduire le cérémonial de C# une version à la fois. Les usings globaux, les déclarations de haut niveau, et maintenant les fichiers .cs autonomes, sont autant d'étapes pour rendre C# viable pour des tâches rapides qui nécessitaient auparavant des scripts Python ou bash.

Ajout de saisie utilisateur

[3:26 - 5:43] Tim remplace l'approche des arguments par une saisie interactive pour démontrer que l'exécution basée sur un fichier prend en charge la gamme complète des modèles d'application console :

Console.Write("What is your name? ");
string name = Console.ReadLine();
Console.WriteLine($"Hello {name}");

Console.Write("What is your name? ");
string name = Console.ReadLine();
Console.WriteLine($"Hello {name}");

L'exécution de ceci invite à saisir une entrée, lit la réponse et affiche le message de salutation. Le standard I/O fonctionne de la même manière qu'un projet complet.

Une limitation que Tim souligne : ce mode est strictement mono-fichier. Vous ne pouvez pas avoir deux fichiers .cs se référant l'un à l'autre. Si votre code se développe au point où vous avez besoin de plusieurs fichiers, il est temps de le convertir en projet (expliqué plus tard dans la vidéo).

Importer des paquets NuGet

[5:43 - 7:49] C'est là que l'approche à fichier unique devient vraiment utile pour le script. Vous pouvez référencer des packages NuGet directement dans le fichier .cs en utilisant une directive #r en haut :

#r "nuget:Spectre.Console, 0.54.0"
using Spectre.Console;

Console.Write("What is your name? ");
string name = Console.ReadLine();
AnsiConsole.MarkupLine($"Hello [red]{name}[/]");

#r "nuget:Spectre.Console, 0.54.0"
using Spectre.Console;

Console.Write("What is your name? ");
string name = Console.ReadLine();
AnsiConsole.MarkupLine($"Hello [red]{name}[/]");

La syntaxe #r "nuget:..." indique à l'exécution de télécharger et référencer le package spécifié avant la compilation. Tim utilise Spectre.Console pour coloriser la sortie, rendant le texte de salutation rouge.

Pas de commande dotnet add package, pas de .csproj à éditer, pas d'étape de restauration. La référence de package réside dans le fichier source lui-même. Pour les scripts nécessitant un client HTTP, un sérialiseur JSON ou une bibliothèque de formatage, cela élimine le besoin de créer un projet juste pour intégrer une dépendance.

Publier en un exécutable natif

[7:49 - 8:59] Lorsque vous souhaitez distribuer un script basé sur un fichier en tant que binaire autonome, la commande de publication le gère :

dotnet publish file demo.cs

dotnet publish file demo.cs

Cela produit un exécutable dans le dossier artifacts. Le binaire compilé inclut tout ce qui est nécessaire pour s'exécuter, sans avoir besoin du SDK .NET sur la machine cible. Tim précise que les constructions basées sur des fichiers utilisent Native AOT par défaut, ce qui signifie que la sortie est un binaire unique, autonome avec des temps de démarrage rapides.

Si Native AOT provoque des problèmes de compatibilité avec une bibliothèque spécifique, vous pouvez le désactiver en ajoutant une directive de propriété en haut du fichier (comme fonctionne #r pour les packages). Pour la plupart des cas d'utilisation de script, cependant, AOT est le bon choix par défaut.

Convertir en projet complet

[8:59 - 10:45] Le recours pour quand un script dépasse le format fichier unique est la commande de conversion :

dotnet project convert file demo.cs

dotnet project convert file demo.cs

Cela génère un fichier .csproj qui inclut les références de packages NuGet des directives #r et déplace le code dans une structure de projet standard. À partir de là, vous pouvez ajouter plusieurs fichiers, configurer les paramètres de build et utiliser le système complet de projet .NET.

Tim présente cela comme une progression naturelle : commencez avec un seul fichier pour des expériences rapides, et quand le champ d'application s'élargit, promouvez-le à un projet sans rien réécrire. Les directives #r se traduisent proprement en entrées <PackageReference> dans le .csproj généré.

Notes sur Native AOT et la plateforme

[10:45 - 12:42] Par défaut, l'exécution basée sur des fichiers compile avec Native AOT, produisant les temps de démarrage les plus rapides possibles. Tim note que c'est idéal pour les outils en ligne de commande et les scripts où la performance de démarrage à froid est importante. Si une bibliothèque n'est pas compatible avec AOT, la fonctionnalité peut être désactivée avec une propriété au niveau du fichier.

Sur Linux et macOS, vous pouvez également ajouter un hashbang (#!/usr/bin/dotnet run file) en haut du fichier .cs, le rendant directement exécutable depuis le shell sans taper le préfixe dotnet run file. Cela plonge C# complètement dans le domaine du scripting aux côtés de bash, Python et Ruby.

Conclusion : C# comme langage de script

[12:42 - 13:05] La fonctionnalité que Tim met en avant comme étant la plus percutante est l'élimination du lourd processus de projet pour les petites tâches. Les applications console ont toujours été le choix pour des expériences rapides, des scripts d'automatisation et des outils ponctuels. L'exécution basée sur des fichiers retire le poids qui faisait que ceux-ci semblaient plus lourds qu'ils ne devaient l'être, tout en conservant chaque avantage (sécurité des types, performance, écosystème de NuGet) qui fait que C# vaut mieux qu'un langage de script.

Conclusion

[13:05 - 13:36] Pour résumer : l'exécution basée sur des fichiers de .NET 10 vous permet d'exécuter un seul fichier .cs avec dotnet run file, de référencer des packages NuGet avec des directives #r, de publier vers un binaire natif avec dotnet publish file, et de convertir en un projet complet avec dotnet project convert file lorsque vous dépassez le format mono-fichier. Native AOT est activé par défaut, et les utilisateurs Linux/macOS bénéficient du support hashbang pour l'exécution au niveau du shell.

Pour tout ce que vous utilisez actuellement comme application console, pour prototyper ou automatiser, cela vaut la peine d'essayer comme une alternative plus légère.

Astuce : Si vous réalisez des applications console juste pour tester un paquet NuGet ou déboguer un appel d'API, essayez l'exécution basée sur un fichier à la place. Créez un fichier .cs, ajoutez #r "nuget:PackageName, Version" en haut, écrivez votre code de test et exécutez-le avec dotnet run file. Quand vous avez terminé, supprimez le fichier. Aucun nettoyage de projet requis.

Regardez la vidéo complète sur sa chaîne YouTube et obtenez plus d'informations sur les flux de travail de développement moderne C#.