FlowingDev

C# Playground, erklärt: Die komplette .NET-Runtime in deinen Browser verfrachtet

Entdecke, wie WebAssembly den echten Roslyn-Compiler und die .NET-Runtime in deinen Browser bringt und das Web in einen nativen C#-Playground verwandelt.

Tool ausprobieren: C# Playground

In einem Satz

Es ist die volle Power der C#-Programmiersprache, des Roslyn-Compilers und der .NET-Runtime, per WebAssembly komplett in deinen Webbrowser teleportiert – was dich Code schreiben, ausführen und zu einer echten DLL kompilieren lässt, ohne eine Multi-Gigabyte-IDE installieren zu müssen.

Das Problem, das es löst

Historisch gesehen war die C#-Entwicklung die Definition von „Heavy Metal“. Geboren in den frühen 2000ern als Microsofts elegante Antwort auf Java, war C# tief an das Windows-Ökosystem gekettet. Wenn du ein kurzes C#-Skript schreiben oder testen wolltest, wie sich eine bestimmte LINQ-Query verhält, konntest du nicht einfach ein Terminal öffnen. Du musstest Visual Studio starten (Zeit für eine Kaffeepause, während der Splash-Screen lud), ein neues Projekt anlegen, ihm einen bedauerlichen Namen wie ConsoleApp42 geben, warten, bis die NuGet-Packages gerestored waren, deine fünf Zeilen Code schreiben, es ausführen und irgendwann den Ordner wieder löschen.

Microsoft hat das revolutioniert, indem sie .NET Open Source gemacht, es Cross-Platform gebracht und die .NET CLI eingeführt haben. Aber selbst dann musstest du immer noch ein fettes SDK herunterladen und installieren, nur um ein simples „Hello, World“ zu kompilieren.

Als Entwickler gieren wir nach sofortigen Feedback-Loops. Wir wollen Algorithmen prototypen, Syntax checken und Bugs mit absolut null Reibungsverlust reproduzieren. Wir brauchen eine Sandbox. Aber für eine statisch typisierte, kompilierte Sprache wie C# bedeutete eine echte Sandbox im Web traditionell, den Code an einen Remote-Backend-Server zu schicken, ihn dort zu kompilieren, ihn in einem Docker-Container laufen zu lassen und den Text-Output zurück an den Browser zu senden. Dieser Ansatz ist lahm, teuer im Hosting und braucht eine ständige Internetverbindung.

Der C#-Playground löst das, indem er den Server komplett eliminiert. Er bringt den Compiler und die Runtime direkt auf den Client und verwandelt deinen Browser in eine ephemere (flüchtige), hyperschnelle Entwicklungsumgebung.

Wie es unter der Haube funktioniert

C# nativ in einem Webbrowser auszuführen, klingt nach schwarzer Magie, ist aber eigentlich die elegante Kombination aus zwei massiven Engineering-Meilensteinen: WebAssembly und dem Roslyn-Compiler.

Die WebAssembly-Runtime

WebAssembly (Wasm) ist ein binäres Instruktionsformat, das als portables Compilation Target fürs Web designt wurde. Es erlaubt Sprachen wie C, C++ und Rust, im Browser in nahezu nativer Geschwindigkeit zu laufen.

Um C# in den Browser zu bringen, hat Microsoft C# nicht in JavaScript neu geschrieben. Stattdessen haben sie die .NET-Runtime (historisch die Mono-Runtime, jetzt vereint unter .NET Wasm) genommen und ihren C/C++-Kern in WebAssembly kompiliert. Wenn du einen C#-Playground lädst, lädt dein Browser die Datei dotnet.wasm herunter. Das ist eine voll funktionsfähige .NET Virtual Machine, die direkt innerhalb der V8-Engine (oder SpiderMonkey, oder JavaScriptCore) deines Browsers läuft.

Roslyn: Der Compiler als Service

Bevor die .NET-Runtime deinen Code ausführen kann, muss er von menschenlesbarem C# in die Microsoft Intermediate Language (MSIL, oder einfach IL) kompiliert werden.

Auftritt Roslyn. Im Gegensatz zu älteren Compilern, die als Black Box agierten (Source Code geht rein, ein Executable kommt raus), wurde Roslyn von Grund auf in C# mit einem satten Set an APIs gebaut. Es ist ein „Compiler as a Service“. Weil Roslyn in C# geschrieben ist und wir dank Wasm eine .NET-Runtime haben, die im Browser läuft, können wir den Roslyn-Compiler tatsächlich innerhalb des Browsers ausführen.

Die Ausführungs-Pipeline

Wenn du Code in den Playground tippst und auf Run klickst, passiert Folgendes – komplett im RAM deiner Maschine:

  1. Parsing: Der In-Browser-Roslyn-Compiler parst deinen Raw-Text in einen Syntax Tree.
  2. Compilation: Roslyn kompiliert den Syntax Tree in eine In-Memory-Assembly (IL-Bytecode).
  3. Execution: Die In-Browser-.NET-Wasm-Runtime lädt diese In-Memory-Assembly und führt die IL-Instruktionen aus. Der Standard-Output (wie Console.WriteLine) wird abgefangen und auf deinen Screen gepiped.

Exportieren der DLL

Weil Roslyn eine echte Standard-Kompilierung durchführt, ist die resultierende In-Memory-Assembly funktional identisch mit den .dll-Dateien auf deinem Desktop. Der Playground kann sich dieses Byte-Array einfach aus dem Speicher greifen und einen Browser-Download triggern. Du kriegst hier keine „Mock“-DLL; du bekommst eine echte Standard-.NET-Library, kompiliert von der offiziellen Engine, bereit, um direkt auf einen Server, in ein Unity-Spiel oder in eine Desktop-App gedroppt zu werden.

Praxis-Szenarien

Die „Kompiliert das?“-Diskussion

Zwei Entwickler steckten tief in einem Pull-Request-Review. Der eine bestand darauf, dass eine bestimmte Kombination aus C# 12 Pattern Matching und switch-Expressions wegen „unreachable code“ einen Compiler-Error werfen würde; der andere schwor, dass es valide Syntax sei. Keiner hatte Bock auf einen Context-Switch, seine lokalen Git-Änderungen zu stashen und einen neuen Test-Branch hochzuziehen. Stattdessen pasteten sie das Snippet in einen C#-Playground im Browser. Innerhalb von drei Sekunden kompilierte der Code, warf das erwartete Ergebnis aus und klärte die Wette augenblicklich. Die Lektion: Der schnellste Weg, eine Debatte über Sprach-Semantik zu beenden, ist ein sofortiger, reibungsloser Feedback-Loop.

Der Quick-and-Dirty-DLL-Builder

Ein Consultant arbeitete an einem dichtgemachten Kunden-Laptop und hatte keine Admin-Rechte, um das .NET SDK zu installieren. Er musste dringend eine kleine Utility-Funktion schreiben, um proprietäre Log-Formate zu parsen, die von der Hauptanwendung (die Drag-and-Drop-Plugin-DLLs unterstützte) verwendet werden sollte. Anstatt drei Tage auf ein IT-Helpdesk-Ticket zu warten, um Visual Studio zu installieren, öffnete der Consultant einen C#-Playground, schrieb die Parsing-Logik, exportierte die kompilierte DLL und droppte sie direkt in den Plugin-Ordner der Anwendung. Die Lektion: Wenn der Browser einen echten Compiler am Start hat, wird er zu einem absolut brauchbaren Build-Server, der Restriktionen auf der lokalen Maschine elegant umgeht.

Das Sandbox-Interview

Ein Tech Lead führte ein Remote-Tech-Interview. Anstatt den Kandidaten zu zwingen, sein klobiges IDE-Setup via Screenshare zu teilen oder sich mit der Latenz eines Remote-Desktops herumzuschlagen, loggten sich beide in eine geteilte C#-Playground-Session ein. Der Kandidat konnte komplexe LINQ-Queries zusammenbauen und objektorientierte Datenstrukturen mit Echtzeit-Feedback testen – und so seine Skills beweisen, ohne den Stress der Environment-Config. Die Lektion: Eine pure, umgebungsfreie Sandbox isoliert die reinen Coding-Fähigkeiten des Entwicklers von seinen System-Admin-Skills.

Häufige Fehler und Fallen

  • Die Annahme, dass du ein echtes Dateisystem hast: Du kannst zwar System.IO-Klassen verwenden, aber du interagierst mit einem virtuellen, flüchtigen Dateisystem der WebAssembly-Umgebung. Wenn du eine Datei unter C:\temp\log.txt schreibst, lebt die im Browser-Memory und verschwindet in der Sekunde, in der du die Seite aktualisierst.
  • Der Aufruf nativer OS-Libraries: Der Versuch, über Platform Invocation Services (P/Invoke) native Windows-APIs wie [DllImport("user32.dll")] aufzurufen, wird gnadenlos schiefgehen. Dein Betriebssystem ist jetzt der Webbrowser; native Desktop-Bibliotheken existieren hier schlicht nicht.
  • Es wie einen High-Performance-Cluster behandeln: WebAssembly ist schnell, aber durch den Browser stark in einer Sandbox eingesperrt und oft bei RAM und Threading limitiert. Ein Playground ist genial, um Logik zu testen, aber miserabel, um ein parallelisiertes Parallel.ForEach über ein Zwei-Gigabyte-Dataset zu jagen.
  • Die async void-Falle: Wenn man schnelle Skripte hackt, vergisst man leicht, dass Main einen async Task zurückgeben muss, falls man Operationen awaitet. Ein async void in einer Sandbox kann dazu führen, dass die Runtime den Execution Context plattmacht, bevor deine asynchronen Tasks überhaupt fertig sind – was in stillen, schwer zu findenden Fehlern (Silent Failures) endet.
  • Assembly-Referenzen vergessen: Wenn du versuchst, eine DLL zu exportieren, vergiss nicht, dass dein Code gegen die Base Class Libraries kompiliert wird, die in der Sandbox existieren. Wenn du dich auf externe Third-Party-NuGet-Packages verlässt, die nicht in den Roslyn-Context des Playgrounds geladen wurden, wird dein Code nicht kompilieren.

Warum du es auf dem Radar haben solltest

Du solltest immer dann zu einem C#-Playground greifen, wenn der mentale oder physische Overhead einer vollen IDE in keinem Verhältnis zur anstehenden Aufgabe steht. Es ist das perfekte Tool, um neue Sprach-Features (wie Primary Constructors oder Collection Expressions in neueren C#-Releases) anzutesten, ohne gleich deine lokale Toolchain upzugraden.

Es ist außerdem unbezahlbar, wenn man reproduzierbare Beispiele teilen will. Wenn du einen Bug in einer Open-Source-Library findest oder eine Frage auf StackOverflow stellen willst, ist ein Link zu einem Playground, in dem exakt dieses Verhalten sofort reproduzierbar ist, unendlich viel hilfreicher, als eine „Wall of Text“ zu posten und zu hoffen, dass die andere Person ihre Umgebung richtig aufsetzt. Und nicht zuletzt macht die Möglichkeit, mühelos eine echte .dll zu exportieren, den Playground zu einem mächtigen Zero-Install-Kompilierungs-Tool, um Lightweight-Plugins und Helper-Libraries mal eben „on the fly“ zu generieren.

Tiefer eintauchen

Theorie erledigt. Zeit, loszulegen — 100 % in deinem Browser.

Tool ausprobieren: C# Playground