LeadByExample(): Jakub Chodounsky o pragmatycznej inżynierii, mentalności YOLO i dlaczego najlepsze praktyki nie zawsze są najlepsze

Process API: najbardziej znacząca aktualizacja od lat

System.Diagnostics.Process otrzymuje swoją pierwszą istotną aktualizację od kilku cykli wydaniowych, i adresuje ona dokładnie punkty bólu, które autorzy bibliotek starali się obejść przez lata. Jest to bezpośrednio istotne dla naszej pracy. IronPDF wewnętrznie owija proces renderowania Chromium, co oznacza, że nasz zespół stworzył i utrzymywał niestandardowe rozwiązania na tym samym obszarze, który Microsoft teraz zstandaryzował: inicjowanie procesów, przechwytywanie wyjścia bez blokady, zarządzanie czasem życia między platformami i wiarygodne zachowanie przy zakończeniu.

Nowa powierzchnia API brzmi jak katalog problemów, z którymi zespoły bibliotek zmagały się przez lata:

// One-line execution with no deadlock risk
string output = await Process.RunAndCaptureTextAsync("git", ["log", "-5"]);

// Cross-platform parent-exit behavior
var psi = new ProcessStartInfo("renderer.exe")
{
    KillOnParentExit = true,
};

// One-line execution with no deadlock risk
string output = await Process.RunAndCaptureTextAsync("git", ["log", "-5"]);

// Cross-platform parent-exit behavior
var psi = new ProcessStartInfo("renderer.exe")
{
    KillOnParentExit = true,
};

Imports System.Diagnostics
Imports System.Threading.Tasks

' One-line execution with no deadlock risk
Dim output As String = Await Process.RunAndCaptureTextAsync("git", {"log", "-5"})

' Cross-platform parent-exit behavior
Dim psi As New ProcessStartInfo("renderer.exe") With {
    .KillOnParentExit = True
}

RunAndCaptureTextAsync multipleksuje stdout i stderr, eliminując blokady bufora. KillOnParentExit i StartDetached zapewniają międzyplatformową kontrolę nad czasem życia procesów potomnych na Windows i Linux. InheritedHandles umożliwia jednoznaczną specyfikację, które uchwyty dziedziczy proces potomny, zastępując historyczne domyślne szerokie dziedziczenie. Lekka powierzchnia SafeProcessHandle produkuje natywne binaria AOT do 20% mniejsze niż standardowe API.

Dla każdego zespołu budującego oprogramowanie .NET, które orkiestruje procesy potomne, ta część notatek wydania wymaga starannej analizy.

Dla zespołów, które nie chcą budować i utrzymywać tej infrastruktury wewnętrznie, IronPDF dostarcza produkcyjnie testowane implementacje tych wzorców z pudełka: przechwytywanie wyjścia bez blokady, kontrolę żywotności i wiarygodne zarządzanie niepowodzeniami. Rozpocznij bezpłatną wersję próbną Iron Suite, nie wymaga karty kredytowej.

APIs Span-based Deflate, ZLib i GZip

Ta zmiana jest mniej widoczna w notatkach wydania, ale faktycznie poprawia każdy ciężar roboczy, który przetwarza dane skompresowane. Dokumenty PDF zawierają strumyki zawartości skompresowanej. Pliki XLSX są archiwami ZIP skompresowanego XML. DOCX podąża za tym samym wzorcem. Nowe API kodera i dekodera oparte na spanach redukuje alokacje w operacjach, które biblioteki takie jak IronPDF i IronXL wykonują ciągle.

Są to ulepszenia na poziomie infrastruktury, które rzadko trafiają na nagłówki wydania, ale redukują koszt każdego przetworzonego bajtu przez framework.

Runtime Async, teraz skompilowany w biblioteki frameworkowe

Preview 3 usunął bramę funkcji podglądu na Runtime Async. Preview 4 rozwija to dalej: same biblioteki środowiska uruchomieniowego (całe BCL, w tym System.IO i System.Net.Http) są teraz skompilowane z runtime-async. Każde wywołanie asynchroniczne do frameworka teraz wykorzystuje nową maszynerię kontynuacyjną, niezależnie od tego, czy kod konsumpcyjny włączył tę funkcję.

Dla bibliotek, które wykonują znaczne I/O (czytanie plików, pobieranie zdalnych zasobów, strumieniowanie bajtów przez kodeki), to oznacza znaczącą poprawę wydajności zależności bez żadnych zmian po stronie konsumenta. Andy Gocke z zespołu środowiska uruchomieniowego potwierdził, że ręcznie włączony DecompressAsync nie produkuje dodatkowych alokacji, gdy jest obsługiwany przez MemoryStream. Microsoft nie opublikował jeszcze oficjalnych liczb benchmarków, powołując się na potrzebę zakończenia pełnego zestawu testów wydajnościowych, ale strukturalna zmiana jest już wdrożona.

MAUI przechodzi na CoreCLR

To najbardziej znacząca zmiana architektoniczna w wydaniu, chociaż bezpośredni wpływ na nasze linie produktów jest ograniczony. Poczynając od Preview 4, aplikacje MAUI na Androidzie, iOS i Mac Catalyst działają domyślnie na CoreCLR, co kończy ponad piętnastoletnią dominację Mono jako środowiska mobilnego dla .NET. To samo środowisko napędza teraz ASP.NET Core, aplikacje stacjonarne i mobilne. dotnet watch jest także teraz dostępny na Androida i iOS, co rozwiązuje jeden z najczęściej wymienianych braków w doświadczeniu deweloperów MAUI od chwili jego wydania.

Dla zespołów korzystających z IronBarcode lub IronPDF w aplikacji MAUI, podstawowe środowisko uruchomieniowe jest teraz jednolite z resztą stosu .NET.

Znane ograniczenia i rozważania

• Wsparcie Visual Studio pozostaje ograniczone do kanału Insiders. Zespoły na stabilnych wydaniach Visual Studio nie integrują jeszcze .NET 11 w głównym rozwoju.
• Runtime Async został strukturalnie wdrożony, ale brakuje oficjalnych benchmarków. Powszechnie rozpowszechnione dane '10M awaits: 80ms do 32ms, 687MB do 94KB' pochodzą z gista społeczności, a nie z Microsoft.
• Przejście MAUI na CoreCLR jest zmianą środowiska uruchomieniowego wysyłaną jako domyślna. Istniejące aplikacje MAUI powinny być testowane na rzeczywistych urządzeniach, a nie zakładane jako przezroczyste uaktualnienie.
• Jak przy każdym podglądzie, wdrożenie produkcyjne powinno poczekać na przynajmniej pierwszego kandydata na wydanie.

Podsumowanie

Preview 4 reprezentuje najsilniejszy zestaw zmian w cyklu .NET 11 do tej pory. Przepisywanie Process API to najważniejsza aktualizacja dla zespołów budujących lub obsługujących oprogramowanie .NET, które inicjuje procesy potomne. Ulepszenia kompresji i Runtime Async kumulują się w ramach zadań intensywnie wykorzystujących I/O. Historia środowiska uruchomieniowego MAUI jest teraz zgodna z resztą platformy.

Nasz zespół aktywnie śledzi każdy podgląd i przygotowuje nasze biblioteki do kompatybilności z dniem pierwszej dostępności publicznej .NET 11, gdy nadejdzie w listopadzie.