FlowingDev

C# Playground, explicado: enviando todo o runtime do .NET para o seu navegador

Descubra como o WebAssembly traz o verdadeiro compilador Roslyn e o runtime do .NET para o seu navegador, transformando a web em um C# playground nativo.

Testar a ferramenta: C# Playground

Em uma frase

É todo o poder da linguagem de programação C#, do compilador Roslyn e do runtime do .NET teletransportados inteiramente para o seu navegador usando WebAssembly — permitindo que você escreva, execute e compile código para uma DLL real sem precisar instalar uma IDE de vários gigabytes.

O problema que ele resolve

Historicamente, o desenvolvimento em C# era a definição de software "pesadão". Nascido no início dos anos 2000 como a resposta elegante da Microsoft ao Java, o C# estava profundamente acorrentado ao ecossistema Windows. Se você quisesse escrever um script rápido em C# ou testar como uma query LINQ específica se comportava, você não podia simplesmente abrir um terminal. Você precisava abrir o Visual Studio (hora da pausa pro café enquanto a tela de carregamento passava), criar um novo projeto, dar a ele um nome lamentável como ConsoleApp42, esperar os pacotes NuGet serem restaurados, escrever suas cinco linhas de código, rodar e, eventualmente, deletar a pasta.

A Microsoft revolucionou isso ao abrir o código do .NET (open-source), tornando-o multiplataforma e introduzindo a .NET CLI. Mas, mesmo assim, você ainda precisava baixar e instalar um SDK pesado só para compilar um simples "Hello, World".

Como pessoas desenvolvedoras, nós ansiamos por ciclos de feedback instantâneos (feedback loops). Queremos prototipar algoritmos, verificar sintaxe e reproduzir bugs com zero atrito. Precisamos de um sandbox. Mas para uma linguagem fortemente tipada e compilada como C#, criar um sandbox verdadeiro na web tradicionalmente significava enviar o código para um servidor backend remoto, compilar lá, rodar dentro de um container Docker e enviar a saída de texto de volta para o navegador. Essa abordagem é lenta, cara para hospedar e exige uma conexão constante com a internet.

O C# playground resolve isso eliminando o servidor por completo. Ele traz o compilador e o runtime diretamente para o client, transformando seu navegador em um ambiente de desenvolvimento efêmero e ultra-rápido.

Como funciona por baixo dos panos

Rodar C# nativamente em um navegador web soa como magia negra, mas na verdade é a combinação elegante de duas grandes conquistas da engenharia: WebAssembly e o Compilador Roslyn.

O Runtime do WebAssembly

O WebAssembly (Wasm) é um formato de instrução binária projetado como um alvo de compilação portável para a web. Ele permite que linguagens como C, C++ e Rust rodem no navegador em velocidades quase nativas.

Para fazer o C# rodar no navegador, a Microsoft não reescreveu o C# em JavaScript. Em vez disso, eles pegaram o Runtime do .NET (historicamente o runtime do Mono, agora unificado sob o .NET Wasm) e compilaram seu núcleo C/C++ para WebAssembly. Quando você carrega um C# playground, seu navegador baixa o dotnet.wasm. Esta é uma Máquina Virtual .NET (VM) totalmente funcional rodando diretamente dentro da engine V8 (ou SpiderMonkey, ou JavaScriptCore) do seu navegador.

Roslyn: O Compilador como Serviço

Antes que o runtime do .NET possa executar seu código, ele precisa ser compilado de um C# legível por humanos para a Microsoft Intermediate Language (MSIL, ou apenas IL).

Aí entra o Roslyn. Diferente dos compiladores mais antigos que agiam como caixas-pretas (código-fonte entra, executável sai), o Roslyn foi construído do zero em C# com um conjunto rico de APIs. Ele é um "Compilador como Serviço" (Compiler as a Service). Como o Roslyn é escrito em C# e temos um runtime do .NET executando no navegador via Wasm, nós podemos, de fato, rodar o compilador Roslyn dentro do navegador.

O Pipeline de Execução

Quando você digita o código no playground e clica em rodar, é isso que acontece inteiramente dentro da memória da sua máquina:

  1. Parsing: O compilador Roslyn no navegador faz o parse (análise) do seu texto puro e o transforma em uma Árvore de Sintaxe (Syntax Tree).
  2. Compilação: O Roslyn compila a Syntax Tree em um assembly em memória (bytecode IL).
  3. Execução: O runtime do .NET Wasm no navegador carrega este assembly da memória e executa as instruções IL. A saída padrão (standard output, como Console.WriteLine) é interceptada e direcionada para a sua tela.

Exportando a DLL

Como o Roslyn está fazendo uma compilação real e padronizada, o assembly resultante na memória é funcionalmente idêntico aos arquivos .dll no seu desktop. O playground pode simplesmente pegar esse array de bytes da memória e acionar um download no navegador. Você não está recebendo uma DLL de "mentirinha" (um mock); você está recebendo uma biblioteca .NET padrão compilada pela engine oficial, pronta para ser jogada num servidor, num jogo da Unity ou num app desktop.

Histórias do mundo real

A discussão "Será que isso compila?"

Dois devs estavam imersos na revisão de um pull request (PR). Um insistia que usar uma combinação específica de pattern matching do C# 12 e expressões switch lançaria um erro de compilação por causa de código inatingível (unreachable code); o outro jurava de pé junto que era uma sintaxe válida. Nenhum dos dois queria fazer troca de contexto (context-switch), dar um stash nas alterações locais do git e subir uma nova branch de teste. Em vez disso, eles colaram o trecho de código em um C# playground no navegador. Em três segundos, o código compilou, imprimiu o resultado esperado e resolveu a aposta na hora. A lição: A maneira mais rápida de encerrar um debate sobre semântica de linguagem é com um ciclo de feedback instantâneo e sem atritos.

O construtor de DLLs "quebra-galho"

Uma consultora estava trabalhando num laptop de cliente totalmente bloqueado, onde ela não tinha direitos de administrador para instalar o SDK do .NET. Ela precisava urgentemente escrever uma pequena função utilitária para fazer o parse de formatos de log proprietários, que a sua aplicação principal (que suportava DLLs de plugins via drag-and-drop) poderia usar. Em vez de esperar três dias por um ticket no suporte de TI para instalar o Visual Studio, a consultora abriu um C# playground, escreveu a lógica de parsing, exportou a DLL compilada e a jogou direto na pasta de plugins da aplicação. A lição: Quando o navegador tem um compilador de verdade, ele se torna um servidor de build perfeitamente viável que contorna as restrições da máquina local.

A entrevista no sandbox

Um tech lead estava conduzindo uma entrevista técnica remota. Em vez de forçar a pessoa candidata a compartilhar a tela de uma configuração de IDE desajeitada ou lidar com o lag de um acesso remoto, ambos logaram numa sessão compartilhada do C# playground. O candidato conseguiu construir queries LINQ complexas e testar estruturas de dados orientadas a objetos com feedback em tempo real, provando suas habilidades sem o estresse da configuração do ambiente. A lição: Um sandbox puro, livre de ambiente, isola a habilidade bruta de programação do dev das suas habilidades de administração de sistemas.

Erros comuns e pegadinhas

  • Assumir que você tem um sistema de arquivos real: Você até pode usar classes do System.IO, mas está interagindo com um sistema de arquivos virtual e efêmero fornecido pelo ambiente do WebAssembly. Se você escrever um arquivo em C:\temp\log.txt, ele viverá na memória do navegador e desaparecerá no instante em que você der um F5 na página.
  • Invocar bibliotecas nativas do SO: Tentar usar serviços do Platform Invocation (P/Invoke) para chamar APIs nativas do Windows, como [DllImport("user32.dll")], vai falhar miseravelmente. Seu sistema operacional agora é o navegador; bibliotecas nativas de desktop não existem aqui.
  • Tratar isso como um cluster de alta performance: O WebAssembly é rápido, mas roda num sandbox rigoroso do navegador e muitas vezes possui restrições de memória e de capacidades de threading. Um playground é brilhante para testar lógica, mas horrível para rodar um Parallel.ForEach paralelizado em cima de um dataset de dois gigabytes.
  • A armadilha do async void: Ao escrever scripts rápidos, é fácil esquecer que o Main precisa retornar uma async Task se você estiver aguardando operações (com await). Usar async void num sandbox pode fazer o runtime desligar o contexto de execução antes que suas tasks assíncronas terminem de verdade, resultando em falhas silenciosas.
  • Esquecer das referências de assembly: Se você estiver tentando exportar uma DLL, lembre-se que seu código é compilado contra as bibliotecas base (Base Class Libraries) fornecidas no sandbox. Se o seu código depender de pacotes NuGet de terceiros que não estão carregados no contexto do Roslyn do playground, ele não vai compilar.

Por que isso deve estar no seu radar

Você deve recorrer a um C# playground sempre que a carga mental ou física de usar uma IDE completa superar a tarefa que tem em mãos. É a ferramenta perfeita para brincar com novos recursos da linguagem (como explorar primary constructors ou collection expressions nas versões mais recentes do C#) sem precisar atualizar o seu toolchain local.

É também um recurso inestimável para compartilhar exemplos reprodutíveis. Se você encontrar um bug numa biblioteca open-source ou quiser fazer uma pergunta no StackOverflow, fornecer o link de um playground onde o comportamento exato pode ser reproduzido instantaneamente é infinitamente mais útil do que colar uma parede de texto e torcer para a outra pessoa configurar o ambiente dela corretamente. Por fim, a capacidade de exportar uma .dll real sem esforço torna o playground uma ferramenta de compilação poderosa, de "instalação-zero", para gerar plugins leves e bibliotecas auxiliares na hora (on the fly).

Vá mais fundo

Teoria feita. Hora de pôr a mão na massa — 100% no seu navegador.

Testar a ferramenta: C# Playground