.NET 11 w końcu naprawia API Procesów

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

Każdy deweloper .NET, który kiedykolwiek musiał uruchomić proces i przechwycić jego wynik, napisał jakąś wariację tego samego niebezpiecznego powtarzającego się kodu: asynchroniczny odczyt z stdout, asynchroniczny odczyt z stderr, WaitForExitAsync, nie zapomnij opróżnić obu strumieni, albo dostaniesz deadlock. To dobrze znana pułapka, która istnieje od lat.

.NET 11 w końcu naprawia to porządnie.

RunAndCaptureTextAsync

Kluczowe dodanie: jedna statyczna metoda, która uruchamia proces, przechwytuje stdout i stderr, i czeka na zakończenie bez deadlocka.

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

Jedno wywołanie. Bez ręcznego opróżniania strumieni. Bez ostrożnie umieszczonego WaitForExit. Jeśli po prostu chcesz uruchomić coś i uzyskać wynik, to jest właśnie to API, którego szukasz.

Jest też Process.RunAsync dla przypadku, gdy chcesz czekać na zakończenie bez przechwytywania danych wyjściowych.

KillOnParentExit

Częsty problem z uruchamianymi procesami: jeśli proces nadrzędny ulega awarii lub zostaje zabity, procesy potomne nadal działają jako sieroty. KillOnParentExit pozwala zadeklarować przy uruchamianiu procesu, że proces potomny powinien zostać zakończony, gdy zakończy się proces nadrzędny.

Ta funkcja istniała w specyficznych dla platformy formach (obiekty zadań w Windows, prctl w Linux), ale wymagała p/invoke lub bibliotek zewnętrznych do użycia z .NET. Teraz jest właściwością pierwszej klasy w ProcessStartInfo.

API oparte na SafeProcessHandle

Nowa lekka powierzchnia API jest zbudowana wokół SafeProcessHandle, a nie pełnej klasy Process. Pełna klasa Process niesie ze sobą dużo stanu i trudno ją przycinać — ścieżka SafeProcessHandle jest bardziej przyjazna dla trimmera w aplikacjach, które muszą minimalizować rozmiar wyjścia (WASM, natywne AOT).

Pełna Kontrola nad Dziedziczeniem Uchwytów

Aktualizacja dodaje również szczegółową kontrolę nad tym, które uchwyty dziedziczy proces potomny i jak są przekierowywane standardowe uchwyty. Wcześniej można było przekierowywać stdin/stdout/stderr, ale nie można było określić dokładnie, które uchwyty dziedziczyć na poziomie systemu operacyjnego. Nowe API udostępniają tę kontrolę.

Dlaczego To Jest Ważne

Klasa Process jest używana w toolingu, systemach budowania, uruchomieniach testów i każdej aplikacji, która wywołuje inne pliki wykonywalne. Stara powierzchnia API pochodzi z epoki .NET Framework i pokazywała swój wiek. Nie jest to zmiana łamiąca kompatybilność — stare API nadal działają — ale nowy kod powinien preferować nową powierzchnię.

W przypadku przycinanych aplikacji lub scenariuszy kompilacji AOT, ścieżka SafeProcessHandle jest szczególnie mile widziana. Stara klasa Process przynosiła dużo kodu z ciężkimi odwołaniami refleksji, który komplikował przycinanie.

Oryginalny post: Process API Improvements in .NET 11

.NET 11 Preview 4: Szablon Serwera MCP, Biblioteki Runtime-Async, API Procesów

Emiliano Montesdeoca — Mon, 25 May 2026 00:00:00 +0000

.NET 11 Preview 4 jest dostępny. Każde wydanie głównej wersji zapoznawczej .NET dodaje długą listę elementów obejmujących runtime, SDK, biblioteki, ASP.NET Core, MAUI, C# i Entity Framework. Zamiast powtarzać pełną listę, oto rzeczy, które przykuły moją uwagę.

Szablon Serwera MCP w SDK .NET

Najciekawszy element: szablon projektu serwera MCP jest teraz zawarty w SDK. Oznacza to, że dotnet new mcp-server (lub jak ostatecznie będzie nazywać się polecenie) działa od razu. Dla każdego, kto buduje narzędzia MCP w .NET, znacznie redukuje to początkowe trudności. Integracja MCP w łańcuchu narzędzi platformy wskazuje kierunek, w którym zmierza ekosystem.

Biblioteki Runtime Skompilowane z Runtime-Async

Sam runtime teraz kompiluje swoje biblioteki standardowe przy użyciu funkcji runtime-async. To wewnętrzna zmiana wpływająca na wydajność — maszyny stanów async w runtime stają się bardziej wydajne. Znaczenie tutaj nie leży w widocznych zmianach API; chodzi o to, że runtime-async jest wystarczająco dojrzały, żeby być używanym w samej BCL, co jest ważnym sygnałem dotyczącym gotowości tej funkcji.

Optymalizacje JIT i Wewnętrzne Funkcje Sprzętowe

Preview 4 kontynuuje prace nad JIT. Ulepszenia wewnętrznych funkcji sprzętowych i generowania kodu trafiają tutaj — szczegóły można znaleźć w informacjach o wydaniu runtime. Tego rodzaju zmiany zazwyczaj poprawiają przepustowość w intensywnych pętlach obliczeniowych bez żadnych zmian w kodzie z twojej strony.

Rozszerzenie API Procesów

Duże aktualizacje System.Diagnostics.Process pojawiają się w Preview 4:

Process.RunAndCaptureTextAsync — uruchom proces, przechwytuj stdout/stderr, poczekaj na zakończenie, wszystko w jednym wywołaniu bez ryzyka deadlocka
KillOnParentExit — lekkie powiązanie cyklu życia między procesem nadrzędnym a podrzędnym
API oparte na SafeProcessHandle, bardziej przyjazne dla trimmera

Jeśli kiedykolwiek pisałeś powtarzający się kod do przechwytywania danych wyjściowych procesu bez powodowania deadlocków (asynchroniczne odczytywanie zarówno z stdout jak i stderr jednocześnie), RunAndCaptureTextAsync jest właśnie tym API, którego brakowało.

dotnet watch dla Android i iOS

dotnet watch teraz obsługuje wybór urządzenia dla projektów .NET MAUI Android i iOS. Szybsza iteracja na urządzeniach mobilnych bez ręcznego zarządzania połączeniami urządzeń w pętli kompilacji.

Oparte na Span API Kompresji

Nowe API kodera/dekodera Deflate, ZLib i GZip oparte na span trafiają do bibliotek. Mniej alokacji przy pracy ze skompresowanymi danymi — istotne w przypadku przetwarzania danych o wysokiej przepustowości.

Wypróbuj

Pobierz .NET 11 Preview 4 — to wersja zapoznawcza, niegotowa na produkcję, ale warto uruchomić ją na swoich projektach, żeby wykryć problemy wcześnie przed cyklem RC.

Oryginalny post: .NET 11 Preview 4 is now available!

.NET 11 | The .NET Blog