FlowingDev

C# Playground, expliqué : embarquer tout le runtime .NET dans votre navigateur

Découvrez comment WebAssembly amène le vrai compilateur Roslyn et le runtime .NET dans votre navigateur, transformant le web en un playground C# natif.

Essayer l'outil: C# Playground

En une phrase

C'est toute la puissance du langage de programmation C#, du compilateur Roslyn et du runtime .NET, téléportée directement dans votre navigateur grâce à WebAssembly — vous permettant d'écrire, d'exécuter et de compiler du code vers une vraie DLL sans installer un IDE de plusieurs gigaoctets.

Le problème qu'il résout

Historiquement, le dev C# était la définition même du "lourd". Né au début des années 2000 comme la réponse élégante de Microsoft à Java, C# était profondément enchaîné à l'écosystème Windows. Si vous vouliez écrire un petit script C# rapide ou tester le comportement d'une requête LINQ spécifique, vous ne pouviez pas juste ouvrir un terminal. Il fallait lancer Visual Studio (le temps d'une pause café pendant le chargement du splash screen), créer un nouveau projet, lui donner un nom regrettable du genre ConsoleApp42, attendre la restauration des packages NuGet, écrire vos cinq lignes de code, l'exécuter, puis finir par supprimer le dossier.

Microsoft a révolutionné tout ça en passant .NET en open-source, en le rendant cross-platform, et en introduisant la .NET CLI. Mais même là, il fallait toujours télécharger et installer un gros SDK juste pour compiler un simple "Hello, World".

En tant que devs, on est accros aux feedback loops instantanées. On veut prototyper des algorithmes, vérifier de la syntaxe et reproduire des bugs avec zéro friction. On a besoin d'une sandbox. Mais pour un langage typé statiquement et compilé comme C#, créer une vraie sandbox sur le web signifiait traditionnellement envoyer le code à un serveur backend distant, le compiler là-bas, l'exécuter dans un conteneur Docker, puis renvoyer la sortie texte au navigateur. Cette approche est lente, chère à héberger, et nécessite une connexion internet permanente.

Le playground C# résout ça en éliminant complètement le serveur. Il amène le compilateur et le runtime directement côté client, transformant votre navigateur en un environnement de développement éphémère et hyper rapide.

Comment ça marche sous le capot

Faire tourner du C# nativement dans un navigateur web ressemble à de la magie noire, mais c'est en fait la combinaison élégante de deux prouesses d'ingénierie massives : WebAssembly et le compilateur Roslyn.

Le Runtime WebAssembly

WebAssembly (Wasm) est un format d'instructions binaire conçu comme une cible de compilation portable pour le web. Il permet à des langages comme C, C++ et Rust de tourner dans le navigateur à une vitesse quasi-native.

Pour faire tourner C# dans le navigateur, Microsoft n'a pas réécrit C# en JavaScript. À la place, ils ont pris le runtime .NET (historiquement le runtime Mono, maintenant unifié sous .NET Wasm) et ont compilé son cœur C/C++ en WebAssembly. Quand vous chargez un playground C#, votre navigateur télécharge dotnet.wasm. C'est une Machine Virtuelle .NET totalement fonctionnelle qui tourne directement à l'intérieur du moteur V8 (ou SpiderMonkey, ou JavaScriptCore) de votre navigateur.

Roslyn : Le compilateur en tant que service

Avant que le runtime .NET puisse exécuter votre code, celui-ci doit être compilé depuis du C# lisible par un humain vers le Microsoft Intermediate Language (MSIL, ou juste IL).

Entrez Roslyn. Contrairement aux anciens compilateurs qui agissaient comme des boîtes noires (le code source entre, un exécutable sort), Roslyn a été construit de zéro en C# avec un ensemble riche d'APIs. C'est un "Compilateur en tant que Service". Parce que Roslyn est écrit en C#, et qu'on a un runtime .NET qui s'exécute dans le navigateur via Wasm, on peut littéralement faire tourner le compilateur Roslyn à l'intérieur du navigateur.

Le pipeline d'exécution

Quand vous tapez du code dans le playground et que vous lancez l'exécution, voici ce qui se passe entièrement dans la mémoire de votre machine :

  1. Parsing : Le compilateur Roslyn in-browser parse votre texte brut pour en faire un Arbre Syntaxique (Syntax Tree).
  2. Compilation : Roslyn compile l'Arbre Syntaxique en un assembly en mémoire (bytecode IL).
  3. Exécution : Le runtime .NET Wasm in-browser charge cet assembly en mémoire et exécute les instructions IL. La sortie standard (comme Console.WriteLine) est interceptée et redirigée (piped) vers votre écran.

L'exportation de la DLL

Puisque Roslyn effectue une vraie compilation standard, l'assembly en mémoire qui en résulte est fonctionnellement identique aux fichiers .dll sur votre bureau. Le playground peut simplement prendre ce tableau d'octets en mémoire et déclencher un téléchargement depuis le navigateur. Vous n'obtenez pas une DLL "factice" ; vous récupérez une librairie .NET standard compilée par le moteur officiel, prête à être glissée dans un serveur, un jeu Unity ou une application desktop.

Anecdotes du monde réel

Le débat du "Est-ce que ça va compiler ?"

Deux développeurs étaient plongés dans la review d'une pull request. L'un insistait sur le fait qu'utiliser une combinaison spécifique de pattern matching C# 12 et d'expressions switch lèverait une erreur de compilation pour code inatteignable ; l'autre jurait que c'était une syntaxe valide. Aucun des deux ne voulait faire un context-switch, stasher ses modifications Git locales et monter une nouvelle branche de test. À la place, ils ont collé le snippet dans un playground C# in-browser. En trois secondes, le code a compilé, affiché le résultat attendu et réglé le pari instantanément. La leçon : La façon la plus rapide de mettre fin à un débat sur la sémantique d'un langage, c'est une feedback loop instantanée et sans friction.

Le builder de DLL quick-and-dirty

Un consultant bossait sur le PC ultra-verrouillé d'un client où il n'avait pas les droits d'administrateur pour installer le SDK .NET. Il avait urgemment besoin d'écrire une petite fonction utilitaire pour parser des formats de logs propriétaires, utilisable par son application principale (qui supportait le drag-and-drop de DLLs sous forme de plugins). Plutôt que d'attendre trois jours qu'un ticket au support IT installe Visual Studio, le consultant a ouvert un playground C#, a écrit sa logique de parsing, exporté la DLL compilée et l'a glissée directement dans le dossier des plugins de l'application. La leçon : Quand le navigateur possède un vrai compilateur, il devient un serveur de build parfaitement viable qui contourne les restrictions de la machine locale.

L'entretien dans la sandbox

Un Tech Lead faisait passer un entretien technique à distance. Au lieu de forcer le candidat à partager l'écran d'une configuration IDE lourdingue ou de subir la latence d'un bureau à distance, ils se sont tous les deux connectés à une session de playground C# partagée. Le candidat a pu construire des requêtes LINQ complexes et tester des structures de données orientées objet avec un feedback en temps réel, prouvant ses compétences sans le stress de la configuration de l'environnement. La leçon : Une pure sandbox sans configuration isole les capacités brutes de code du développeur de ses compétences en administration système.

Erreurs courantes et pièges

  • Croire que vous avez un vrai système de fichiers : Vous pouvez utiliser les classes System.IO, mais vous interagissez avec un système de fichiers virtuel et éphémère fourni par l'environnement WebAssembly. Si vous écrivez un fichier dans C:\temp\log.txt, il vit dans la mémoire du navigateur et disparaît à la seconde où vous rafraîchissez la page.
  • Invoquer des librairies natives de l'OS : Tenter d'utiliser les Platform Invocation Services (P/Invoke) pour appeler des APIs natives Windows comme [DllImport("user32.dll")] échouera de manière hilarante. Votre système d'exploitation est maintenant le navigateur web ; les librairies desktop natives n'existent pas ici.
  • S'en servir comme d'un cluster hautes performances : WebAssembly est rapide, mais il est lourdement sandboxé par le navigateur et souvent restreint en matière de mémoire et de capacités de threading. Un playground est génial pour tester de la logique, mais catastrophique pour faire tourner un Parallel.ForEach parallélisé sur un dataset de deux gigaoctets.
  • Le piège du async void : Quand on écrit des petits scripts rapides, il est facile d'oublier que Main doit retourner une async Task si vous attendez des opérations. Utiliser async void dans une sandbox peut amener le runtime à fermer le contexte d'exécution avant même que vos tâches asynchrones ne se terminent, provoquant des échecs silencieux.
  • Oublier les références d'assembly : Si vous essayez d'exporter une DLL, n'oubliez pas que votre code est compilé contre les base class libraries fournies dans la sandbox. Si vous dépendez de packages NuGet tiers externes qui ne sont pas chargés dans le contexte Roslyn du playground, votre code ne compilera pas.

Pourquoi vous devez l'avoir sur votre radar

Vous devriez dégainer un playground C# chaque fois que l'overhead mental ou physique d'un IDE complet dépasse la tâche à accomplir. C'est l'outil parfait pour tâter le terrain avec de nouvelles features du langage (comme explorer les primary constructors ou les collection expressions dans les récentes versions de C#) sans avoir à mettre à jour votre toolchain locale.

C'est aussi un atout inestimable pour partager des exemples reproductibles. Si vous trouvez un bug dans une librairie open-source ou que vous voulez poser une question sur StackOverflow, fournir un lien vers un playground où le comportement exact est instantanément reproductible est infiniment plus utile que de coller un mur de texte en espérant que l'autre personne configure correctement son environnement. Enfin, la possibilité d'exporter sans effort une vraie .dll en fait un outil de compilation puissant et zero-install pour générer des plugins légers et des librairies utilitaires à la volée.

Pour aller plus loin

Théorie bouclée. Place à la pratique — 100 % dans ton navigateur.

Essayer l'outil: C# Playground