FlowingDev

C# Playground, explained: shipping the entire .NET runtime to your browser

Discover how WebAssembly brings the real Roslyn compiler and .NET runtime to your browser, turning the web into a native C# playground.

Try the tool: C# Playground

In one sentence

It is the full power of the C# programming language, the Roslyn compiler, and the .NET runtime, teleported entirely into your web browser using WebAssembly—letting you write, execute, and compile code to a real DLL without installing a multi-gigabyte IDE.

The problem it solves

Historically, C# development was the definition of "heavy metal." Born in the early 2000s as Microsoft’s elegant answer to Java, C# was deeply chained to the Windows ecosystem. If you wanted to write a quick C# script or test how a specific LINQ query behaved, you couldn't just open a terminal. You had to launch Visual Studio (time for a coffee break while the splash screen loaded), create a new project, name it something regrettable like ConsoleApp42, wait for NuGet packages to restore, write your five lines of code, run it, and then eventually delete the folder.

Microsoft revolutionized this by open-sourcing .NET, making it cross-platform, and introducing the .NET CLI. But even then, you still needed to download and install a hefty SDK just to compile a simple "Hello, World."

As developers, we crave instant feedback loops. We want to prototype algorithms, verify syntax, and reproduce bugs with zero friction. We need a sandbox. But for a statically typed, compiled language like C#, creating a true sandbox on the web traditionally meant sending the code to a remote backend server, compiling it there, running it in a Docker container, and sending the text output back to the browser. That approach is slow, expensive to host, and requires a persistent internet connection.

The C# playground solves this by eliminating the server entirely. It brings the compiler and the runtime directly to the client, transforming your browser into an ephemeral, hyper-fast development environment.

How it works under the hood

Running C# natively in a web browser sounds like dark magic, but it is actually the elegant combination of two massive engineering achievements: WebAssembly and the Roslyn Compiler.

The WebAssembly Runtime

WebAssembly (Wasm) is a binary instruction format designed as a portable compilation target for the web. It allows languages like C, C++, and Rust to run in the browser at near-native speed.

To get C# to run in the browser, Microsoft didn't rewrite C# in JavaScript. Instead, they took the .NET Runtime (historically the Mono runtime, now unified under .NET Wasm) and compiled its C/C++ core into WebAssembly. When you load a C# playground, your browser downloads dotnet.wasm. This is a fully functional .NET Virtual Machine running directly inside the V8 engine (or SpiderMonkey, or JavaScriptCore) of your browser.

Roslyn: The Compiler as a Service

Before the .NET runtime can execute your code, it needs to be compiled from human-readable C# into Microsoft Intermediate Language (MSIL, or just IL).

Enter Roslyn. Unlike older compilers that acted as black boxes (source code goes in, an executable comes out), Roslyn was built from the ground up in C# with a rich set of APIs. It is a "Compiler as a Service." Because Roslyn is written in C#, and we have a .NET runtime executing in the browser via Wasm, we can actually run the Roslyn compiler inside the browser.

The Execution Pipeline

When you type code into the playground and hit run, here is what happens entirely inside your machine's memory:

  1. Parsing: The in-browser Roslyn compiler parses your raw text into a Syntax Tree.
  2. Compilation: Roslyn compiles the Syntax Tree into an in-memory assembly (IL bytecode).
  3. Execution: The in-browser .NET Wasm runtime loads this in-memory assembly and executes the IL instructions. Standard output (like Console.WriteLine) is intercepted and piped to your screen.

Exporting the DLL

Because Roslyn is doing a real, standard compilation, the resulting in-memory assembly is functionally identical to the .dll files on your desktop. The playground can simply take that byte array from memory and trigger a browser download. You aren't getting a "mock" DLL; you are getting a standard .NET library compiled by the official engine, ready to be dropped into a server, a Unity game, or a desktop app.

Real-world stories

The "Will this compile?" argument

Two developers were deep in a pull request review. One insisted that using a specific combination of C# 12 pattern matching and switch expressions would throw a compiler error due to unreachable code; the other swore it was valid syntax. Neither wanted to context-switch, stash their local git changes, and spin up a new test branch. Instead, they pasted the snippet into an in-browser C# playground. Within three seconds, the code compiled, output the expected result, and settled the bet instantly. The lesson: The fastest way to end a debate about language semantics is an instant, frictionless feedback loop.

The quick-and-dirty DLL builder

A consultant was working on a locked-down client laptop where they didn't have administrator rights to install the .NET SDK. They urgently needed to write a small utility function to parse proprietary log formats, which their main application (which supported drag-and-drop plugin DLLs) could use. Rather than waiting three days for an IT helpdesk ticket to install Visual Studio, the consultant opened a C# playground, wrote the parsing logic, exported the compiled DLL, and dropped it straight into the application's plugin folder. The lesson: When the browser has a real compiler, it becomes a perfectly viable build server that bypasses local machine restrictions.

The sandbox interview

A tech lead was conducting a remote technical interview. Instead of forcing the candidate to screen-share a clunky IDE setup or deal with the latency of a remote desktop, they both logged into a shared C# playground session. The candidate could construct complex LINQ queries and test object-oriented data structures with real-time feedback, proving their skills without the stress of environment configuration. The lesson: A pure, environment-free sandbox isolates the developer's raw coding ability from their system administration skills.

Common mistakes and traps

  • Assuming you have a real file system: You can use System.IO classes, but you are interacting with a virtual, ephemeral file system provided by the WebAssembly environment. If you write a file to C:\temp\log.txt, it lives in browser memory and disappears the moment you refresh the page.
  • Invoking OS-native libraries: Attempting to use Platform Invocation Services (P/Invoke) to call native Windows APIs like [DllImport("user32.dll")] will fail hilariously. Your operating system is now the web browser; native desktop libraries do not exist here.
  • Treating it like a high-performance cluster: WebAssembly is fast, but it is heavily sandboxed by the browser and often restricted in memory and threading capabilities. A playground is brilliant for testing logic, but terrible for running a parallelized Parallel.ForEach over a two-gigabyte dataset.
  • The async void trap: When writing quick scripts, it is easy to forget that Main needs to return an async Task if you are awaiting operations. Using async void in a sandbox can lead to the runtime shutting down the execution context before your asynchronous tasks actually finish, resulting in silent failures.
  • Forgetting assembly references: If you are trying to export a DLL, remember that your code is compiled against the base class libraries provided in the sandbox. If you rely on external third-party NuGet packages that aren't loaded into the playground's Roslyn context, your code won't compile.

Why it belongs on your radar

You should reach for a C# playground whenever the mental or physical overhead of a full IDE outweighs the task at hand. It is the perfect tool for testing the waters with new language features (like exploring primary constructors or collection expressions in recent C# releases) without upgrading your local toolchain.

It is also an invaluable asset for sharing reproducible examples. If you find a bug in an open-source library or want to ask a question on StackOverflow, providing a link to a playground where the exact behavior is instantly reproducible is infinitely more helpful than pasting a wall of text and hoping the other person sets up their environment correctly. Finally, the ability to effortlessly export a real .dll makes it a powerful, zero-install compilation tool for generating lightweight plugins and helper libraries on the fly.

Go deeper

Theory done. Time to get your hands dirty — 100% in your browser.

Try the tool: C# Playground