.NET 11 por fin arregla la API de Procesos

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

Todo desarrollador .NET que alguna vez ha necesitado lanzar un proceso y capturar su salida ha escrito alguna variación del mismo boilerplate peligroso: lectura async de stdout, lectura async de stderr, WaitForExitAsync, sin olvidar drenar ambos streams o producirás un deadlock. Es una trampa conocida que lleva años ahí.

.NET 11 finalmente lo arregla correctamente.

RunAndCaptureTextAsync

La adición principal: un único método estático que inicia un proceso, captura stdout y stderr, y espera la salida sin producir deadlock.

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

Una sola llamada. Sin drenaje manual de streams. Sin un WaitForExit colocado cuidadosamente. Si simplemente necesitas ejecutar algo y obtener su salida, esta es la API que quieres.

También existe Process.RunAsync para el caso en que quieras esperar la salida sin capturar el output.

KillOnParentExit

Un problema común con los procesos lanzados: si el padre falla o es terminado, los procesos hijo siguen ejecutándose como huérfanos. KillOnParentExit te permite declarar en el momento de iniciar el proceso que el proceso hijo debe terminar cuando el proceso padre salga.

Esta es una funcionalidad que ha existido de formas específicas de plataforma (job objects en Windows, prctl en Linux), pero requería p/invoke o bibliotecas de terceros para usarla desde .NET. Ahora es una propiedad de primera clase en ProcessStartInfo.

APIs Basadas en SafeProcessHandle

La nueva superficie de API ligera está construida sobre SafeProcessHandle en lugar de la clase Process completa. La clase Process completa lleva mucho estado y es difícil de recortar — la ruta de SafeProcessHandle es más amigable con el trimmer para aplicaciones que necesitan minimizar el tamaño de salida (WASM, AOT nativo).

Control Total Sobre la Herencia de Handles

La actualización también añade control detallado sobre qué handles hereda un proceso hijo y cómo se redirigen los handles estándar. Anteriormente podías redirigir stdin/stdout/stderr, pero no podías especificar exactamente qué handles heredar a nivel de SO. Las nuevas APIs exponen ese control.

Por Qué Importa

La clase Process se usa en tooling, sistemas de build, ejecutores de pruebas y cualquier aplicación que invoca otros ejecutables. La superficie de API anterior databa de .NET Framework y estaba mostrando su edad. No es un cambio que rompe compatibilidad — las APIs antiguas siguen funcionando — pero el nuevo código debería preferir la nueva superficie.

Para aplicaciones recortadas o escenarios de compilación AOT, la ruta de SafeProcessHandle es especialmente bienvenida. La antigua clase Process arrastraba mucho código pesado en reflexión que complicaba el recorte.

Post original: Process API Improvements in .NET 11

Cómo Copilot Studio Migró a .NET 10 WebAssembly y Se Volvió un 20% Más Rápido

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

El equipo de Copilot Studio hizo algo sobre lo que todos los desarrolladores Blazor WASM han sentido curiosidad: actualizaron una aplicación de producción de .NET 8 a .NET 10 y midieron los resultados. La publicación comparte números específicos, algo que es raro y genuinamente útil.

La Actualización Fue Aburrida (Eso es Bueno)

Actualizar el framework de destino, actualizar las referencias de paquetes, corregir los cambios disruptivos. Eso es todo. La compilación de .NET 10 ahora está ejecutándose en producción. La migración en sí no fue la parte interesante — los cambios en .NET 10 sí lo son.

Fingerprinting Automático de Activos

Anteriormente, distribuir una aplicación WASM significaba escribir scripts personalizados para renombrar los activos publicados con hashes SHA256 para la invalidación de caché. Copilot Studio tenía un script PowerShell haciendo exactamente esto — renombrar archivos, inyectar atributos integrity en el cargador JavaScript, gestionar todo manualmente.

En .NET 10, todo eso está integrado. Los activos publicados se marcan automáticamente con fingerprint, se importan directamente desde dotnet.js y se validan con integridad sin intervención manual. El equipo eliminó el script de renombrado.

Pequeño cambio en alcance, reducción significativa de complejidad.

WasmStripILAfterAOT Ahora Está Activado por Defecto

En .NET 8, eliminar IL de los ensamblados compilados AOT era opt-in. En .NET 10 es el valor predeterminado. Después de la compilación AOT, el bytecode IL original se elimina de la salida — no se necesita en tiempo de ejecución, y mantenerlo inflaba el tamaño del paquete sin razón.

Copilot Studio usa una optimización específica: distribuye tanto un motor JIT (inicio rápido) como un motor AOT (rendimiento máximo en estado estable), cargando ambos en paralelo y transfiriendo de JIT a AOT una vez que está listo. También deduplica los archivos idénticos entre los dos motores.

El nuevo comportamiento de eliminación de IL significa que los ensamblados AOT ya no coinciden bit a bit con sus contrapartes JIT, por lo que menos archivos se deduplican:

.NET 8: 59 archivos compartidos
.NET 10: 22 archivos compartidos

Resultado neto: tamaño del paquete aproximadamente un 15% mayor para el motor AOT. La descarga AOT es ~6% más lenta en LAN rápida, ~17% más lenta en 4G. Pero todo sucede en segundo plano después de que la aplicación ya es interactiva.

Los Números de Rendimiento

Esta es la parte que importa:

~20% más rápido en la primera llamada (ruta fría)
~5% más rápido en llamadas posteriores (ruta cálida)

Las mejoras son más visibles en “bots grandes” — agentes grandes y complejos donde domina el código compilado AOT. Para flujos de trabajo más simples la ganancia es menor.

Si Todavía Estás en .NET 8

La historia de migración es genuinamente simple: actualiza <TargetFramework>, actualiza las referencias de paquetes, elimina cualquier script de fingerprinting personalizado, y automáticamente te beneficiarás de WasmStripILAfterAOT. Si estás compilando AOT, espera ganancias de rendimiento similares.

Una nota de la publicación: si cargas el runtime de .NET WASM dentro de un WebWorker, establece dotnetSidecar = true al inicializar.

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

Performance | The .NET Blog