.NET 11 finalmente corrige a API de Processos

Emiliano Montesdeoca — Tue, 26 May 2026 00:00:00 +0000

Todo desenvolvedor .NET que alguma vez precisou lançar um processo e capturar a sua saída escreveu alguma variação do mesmo boilerplate perigoso: leitura async de stdout, leitura async de stderr, WaitForExitAsync, sem esquecer de drenar ambos os streams ou haverá um deadlock. É uma armadilha bem conhecida que existe há anos.

O .NET 11 finalmente resolve isto corretamente.

RunAndCaptureTextAsync

A adição principal: um único método estático que inicia um processo, captura stdout e stderr, e aguarda a saída sem deadlock.

var result = await Process.RunAndCaptureTextAsync("dotnet", "--version");
Console.WriteLine(result.StandardOutput);

Uma única chamada. Sem drenagem manual de streams. Sem WaitForExit cuidadosamente posicionado. Se apenas precisas de executar algo e obter a sua saída, esta é a API que queres.

Existe também Process.RunAsync para o caso em que queres aguardar a saída sem capturar o output.

KillOnParentExit

Um problema comum com processos lançados: se o processo pai falha ou é terminado, os processos filhos continuam a correr como órfãos. KillOnParentExit permite-te declarar no momento de iniciar o processo que o processo filho deve ser terminado quando o processo pai sair.

Esta é uma funcionalidade que existia de formas específicas da plataforma (job objects no Windows, prctl no Linux) mas exigia p/invoke ou bibliotecas de terceiros para ser usada a partir do .NET. Agora é uma propriedade de primeira classe em ProcessStartInfo.

APIs Baseadas em SafeProcessHandle

A nova superfície de API leve é construída em torno de SafeProcessHandle em vez da classe Process completa. A classe Process completa carrega muito estado e é difícil de fazer trim — o caminho SafeProcessHandle é mais amigável ao trimmer para aplicações que precisam minimizar o tamanho de saída (WASM, AOT nativo).

Controlo Total Sobre a Herança de Handles

A atualização também adiciona controlo granular sobre quais handles um processo filho herda e como os handles padrão são redirecionados. Anteriormente podias redirecionar stdin/stdout/stderr mas não podias especificar exatamente quais handles herdar ao nível do SO. As novas APIs expõem esse controlo.

Porquê Isto Importa

A classe Process é usada em tooling, sistemas de build, executores de testes e qualquer aplicação que invoca outros executáveis. A antiga superfície de API datava do .NET Framework e estava a mostrar a sua idade. Não é uma mudança que quebra compatibilidade — as APIs antigas continuam a funcionar — mas o novo código deve preferir a nova superfície.

Para aplicações com trim ou cenários de compilação AOT, o caminho SafeProcessHandle é particularmente bem-vindo. A antiga classe Process trazia muito código pesado em reflexão que complicava o trimming.

Post original: Process API Improvements in .NET 11

Como o Copilot Studio Migrou para .NET 10 WebAssembly e Ficou 20% Mais Rápido

Emiliano Montesdeoca — Sat, 23 May 2026 00:00:00 +0000

A equipe do Copilot Studio fez algo sobre o qual todos os desenvolvedores Blazor WASM estavam curiosos: eles realmente atualizaram uma aplicação de produção do .NET 8 para o .NET 10 e mediram os resultados. O post compartilha números específicos, o que é raro e genuinamente útil.

A Migração Foi Chata (Isso é Positivo)

Atualizar o framework de destino, atualizar as referências de pacotes, corrigir as alterações breaking. É isso. O build do .NET 10 agora está rodando em produção. A migração em si não foi a parte interessante — as mudanças no .NET 10 são.

Fingerprinting Automático de Assets

Anteriormente, distribuir um app WASM significava escrever scripts personalizados para renomear os assets publicados com hashes SHA256 para invalidação de cache. O Copilot Studio tinha um script PowerShell fazendo exatamente isso — renomear arquivos, injetar atributos integrity no loader JavaScript, gerenciar tudo manualmente.

No .NET 10, tudo isso está integrado. Os assets publicados são automaticamente marcados com fingerprint, importados diretamente de dotnet.js e validados com integridade sem intervenção manual. A equipe deletou o script de renomeação.

Pequena mudança em escopo, redução significativa de complexidade.

WasmStripILAfterAOT Agora Está Ativado por Padrão

No .NET 8, remover IL de assemblies compiladas AOT era opt-in. No .NET 10 é o padrão. Após a compilação AOT, o bytecode IL original é removido da saída — não é necessário em tempo de execução, e mantê-lo inflava o tamanho do pacote sem razão.

O Copilot Studio usa uma otimização específica: ele distribui tanto um motor JIT (inicialização rápida) quanto um motor AOT (desempenho máximo em estado estável), carregando ambos em paralelo e transferindo de JIT para AOT quando estiver pronto. Também deduplica arquivos idênticos entre os dois motores.

O novo comportamento de stripping do IL significa que os assemblies AOT não correspondem mais bit a bit com seus equivalentes JIT, então menos arquivos são deduplicados:

.NET 8: 59 arquivos compartilhados
.NET 10: 22 arquivos compartilhados

Resultado líquido: tamanho do pacote aproximadamente 15% maior para o motor AOT. O download AOT é ~6% mais lento em LAN rápida, ~17% mais lento em 4G. Mas tudo acontece em segundo plano depois que o app já está interativo.

Os Números de Desempenho

Esta é a parte que importa:

~20% mais rápido na primeira chamada (caminho frio)
~5% mais rápido nas chamadas subsequentes (caminho quente)

As melhorias são mais visíveis em “bots grandes” — agentes grandes e complexos onde o código compilado AOT domina. Para fluxos de trabalho mais simples o ganho é menor.

Se Você Ainda Está no .NET 8

A história de migração é genuinamente simples: atualize <TargetFramework>, atualize as referências de pacotes, remova quaisquer scripts de fingerprinting personalizados, e você se beneficiará automaticamente do WasmStripILAfterAOT. Se você estiver compilando AOT, espere ganhos de desempenho similares.

Uma nota do post: se você carregar o runtime .NET WASM dentro de um WebWorker, defina dotnetSidecar = true ao inicializar.

Post original: Copilot Studio gets faster with .NET 10 on WebAssembly

Performance | The .NET Blog