FlowingDev

C# Playground, explicado: llevando todo el runtime de .NET a tu navegador

Descubre cómo WebAssembly trae el verdadero compilador Roslyn y el runtime de .NET a tu navegador, convirtiendo la web en un playground nativo de C#.

Probar la herramienta: C# Playground

En una frase

Es todo el poder del lenguaje de programación C#, el compilador Roslyn y el runtime de .NET, teletransportados por completo a tu navegador web usando WebAssembly — permitiéndote escribir, ejecutar y compilar código en una DLL real sin tener que instalar un IDE de múltiples gigabytes.

El problema que resuelve

Históricamente, el desarrollo en C# era la definición de "heavy metal". Nacido a principios de los 2000 como la respuesta elegante de Microsoft a Java, C# estaba profundamente encadenado al ecosistema de Windows. Si querías escribir un script rápido en C# o probar cómo se comportaba una query específica de LINQ, no podías simplemente abrir una terminal. Tenías que lanzar Visual Studio (tiempo de ir por un café mientras cargaba la pantalla de inicio), crear un proyecto nuevo, ponerle un nombre lamentable como ConsoleApp42, esperar a que se restauraran los paquetes de NuGet, escribir tus cinco líneas de código, correrlo, y eventualmente terminar borrando la carpeta.

Microsoft revolucionó esto al hacer .NET open source, volviéndolo multiplataforma y presentando la .NET CLI. Pero incluso entonces, seguías necesitando descargar e instalar un SDK pesadísimo solo para compilar un simple "Hola, Mundo".

Como developers, anhelamos los loops de feedback instantáneo. Queremos prototipar algoritmos, verificar la sintaxis y reproducir bugs con cero fricción. Necesitamos un sandbox. Pero para un lenguaje compilado y de tipado estático como C#, crear un verdadero sandbox en la web tradicionalmente significaba mandar el código a un servidor backend remoto, compilarlo ahí, correrlo en un contenedor de Docker y mandar el output de texto de vuelta al navegador. Ese enfoque es lento, caro de hostear y requiere una conexión a internet persistente.

El playground de C# resuelve esto eliminando el servidor por completo. Trae el compilador y el runtime directo al cliente, transformando tu navegador en un entorno de desarrollo efímero e hiperrápido.

Cómo funciona bajo el capó

Correr C# de forma nativa en un navegador web suena a magia negra, pero en realidad es la combinación elegante de dos logros colosales de ingeniería: WebAssembly y el compilador Roslyn.

El runtime de WebAssembly

WebAssembly (Wasm) es un formato de instrucciones binarias diseñado como un target de compilación portable para la web. Permite que lenguajes como C, C++ y Rust corran en el navegador a velocidades casi nativas.

Para lograr que C# corriera en el navegador, Microsoft no reescribió C# en JavaScript. En vez de eso, tomaron el runtime de .NET (históricamente el runtime de Mono, ahora unificado bajo .NET Wasm) y compilaron su núcleo de C/C++ a WebAssembly. Cuando cargas un playground de C#, tu navegador descarga dotnet.wasm. Esta es una Máquina Virtual de .NET completamente funcional corriendo directo dentro del motor V8 (o SpiderMonkey, o JavaScriptCore) de tu navegador.

Roslyn: El compilador como servicio

Antes de que el runtime de .NET pueda ejecutar tu código, este necesita ser compilado de C# legible por humanos a Microsoft Intermediate Language (MSIL, o simplemente IL).

Aquí entra Roslyn. A diferencia de los compiladores viejos que actuaban como cajas negras (entra código fuente, sale un ejecutable), Roslyn fue construido desde cero en C# con un set muy rico de APIs. Es un "Compilador como Servicio". Y como Roslyn está escrito en C#, y nosotros tenemos un runtime de .NET ejecutándose en el navegador vía Wasm, podemos literalmente correr el compilador Roslyn adentro del navegador.

El pipeline de ejecución

Cuando escribes código en el playground y le das a run, esto es lo que pasa completamente dentro de la memoria de tu máquina:

  1. Parsing: El compilador Roslyn que está en el navegador parsea tu texto crudo y lo convierte en un Syntax Tree (Árbol de Sintaxis).
  2. Compilación: Roslyn compila el Syntax Tree y genera un assembly en memoria (bytecode IL).
  3. Ejecución: El runtime de .NET Wasm del navegador carga este assembly en memoria y ejecuta las instrucciones IL. El standard output (como los Console.WriteLine) se intercepta y se manda a tu pantalla.

Exportando la DLL

Como Roslyn está haciendo una compilación real y estándar, el assembly resultante en memoria es funcionalmente idéntico a los archivos .dll que tienes en tu escritorio. El playground puede simplemente tomar ese array de bytes de la memoria y disparar una descarga en el navegador. No estás obteniendo una DLL "de juguete"; es una librería estándar de .NET compilada por el motor oficial, lista para que la tires en un servidor, un juego de Unity o una app de escritorio.

Historias del mundo real

La discusión de "¿Esto va a compilar?"

Dos developers estaban a full revisando un pull request. Uno insistía en que usar una combinación específica de pattern matching de C# 12 y expresiones switch iba a tirar un error de compilación por código inalcanzable; el otro juraba que era sintaxis válida. Ninguno quería hacer context-switch, hacer stash de sus cambios locales en git y levantar una rama de prueba nueva. En lugar de eso, pegaron el snippet en un playground de C# en el navegador. En tres segundos, el código compiló, imprimió el resultado esperado y resolvió la apuesta al instante. La lección: La manera más rápida de terminar un debate sobre semántica del lenguaje es un loop de feedback instantáneo y sin fricción.

El builder rápido de DLLs

Un consultor estaba trabajando en la laptop súper bloqueada de un cliente donde no tenía permisos de administrador para instalar el SDK de .NET. Necesitaba escribir urgente una pequeña función utilitaria para parsear formatos de log propietarios, que la aplicación principal (que soportaba drag-and-drop de DLLs como plugins) pudiera usar. En vez de esperar tres días a que el soporte de IT resolviera el ticket para instalar Visual Studio, el consultor abrió un playground de C#, escribió la lógica de parseo, exportó la DLL compilada y la soltó directamente en la carpeta de plugins de la aplicación. La lección: Cuando el navegador tiene un compilador real, se convierte en un build server perfectamente viable que esquiva las restricciones de la máquina local.

La entrevista en el sandbox

Un tech lead estaba haciendo una entrevista técnica remota. En lugar de forzar al candidato a compartir pantalla con un setup de IDE tosco o lidiar con el lag de un escritorio remoto, ambos se metieron a una sesión compartida en un playground de C#. El candidato pudo armar queries complejas de LINQ y probar estructuras de datos orientadas a objetos con feedback en tiempo real, demostrando sus habilidades sin el estrés de configurar un entorno. La lección: Un sandbox puro y sin entorno aísla la habilidad de programación cruda del developer de sus habilidades de administración de sistemas.

Errores comunes y trampas

  • Asumir que tienes un sistema de archivos real: Puedes usar las clases de System.IO, pero estás interactuando con un sistema de archivos virtual y efímero proveído por el entorno de WebAssembly. Si escribes un archivo en C:\temp\log.txt, este vive en la memoria del navegador y desaparece en el instante en que refrescas la página.
  • Invocar librerías nativas del SO: Intentar usar los servicios de P/Invoke para llamar a APIs nativas de Windows como [DllImport("user32.dll")] va a fallar de forma hilarante. Tu sistema operativo ahora es el navegador web; las librerías nativas de escritorio no existen aquí.
  • Tratarlo como un clúster de alto rendimiento: WebAssembly es rápido, pero está fuertemente encapsulado (sandboxed) por el navegador y a menudo restringido en cuanto a memoria y capacidades de hilos (threading). Un playground es brillante para probar la lógica, pero pésimo para correr un Parallel.ForEach paralelizado sobre un dataset de dos gigabytes.
  • La trampa del async void: Cuando escribes scripts rápidos, es fácil olvidar que el Main necesita retornar un async Task si estás esperando (awaiting) operaciones. Usar async void en un sandbox puede causar que el runtime cierre el contexto de ejecución antes de que tus tareas asíncronas realmente terminen, provocando fallas silenciosas.
  • Olvidar las referencias de los assemblies: Si estás tratando de exportar una DLL, recuerda que tu código se compila contra las base class libraries provistas en el sandbox. Si dependes de paquetes NuGet externos de terceros que no están cargados en el contexto de Roslyn del playground, tu código no va a compilar.

Por qué debería estar en tu radar

Deberías acudir a un playground de C# siempre que el esfuerzo mental o físico de abrir un IDE completo sea mayor a la tarea que tienes enfrente. Es la herramienta perfecta para probar el terreno con nuevas features del lenguaje (como explorar los primary constructors o las expresiones de colecciones en las versiones recientes de C#) sin tener que actualizar tu toolchain local.

También es un activo invaluable para compartir ejemplos reproducibles. Si encuentras un bug en una librería open-source o quieres hacer una pregunta en StackOverflow, proveer un link a un playground donde el comportamiento exacto se puede reproducir al instante es infinitamente más útil que pegar un muro de texto y rezar para que la otra persona configure su entorno correctamente. Finalmente, la habilidad de exportar sin esfuerzo una .dll real lo convierte en una herramienta de compilación poderosa y de cero instalación para generar plugins ligeros y librerías auxiliares al vuelo.

Para profundizar

Teoría lista. Hora de ensuciarse las manos — 100% en tu navegador.

Probar la herramienta: C# Playground