.NET 11 Preview 3: Recenzja programisty
Każdy zespół posiadający starszą aplikację .NET wie, że aktualizacja nie jest trudną częścią. Zmienianie docelowego frameworka to kwestia popołudnia. Trudniejszą częścią jest wszystko, do czego niepostrzeżenie przywiązała się baza kodu przez dziesięciolecie: zależność, która działa tylko na Windowsie, przepływ danych, którego nikt w pełni nie pamięta, komponent, który psuje się w produkcji, gdy na niego spojrzysz. To jest praca, na której modernizacja zawsze stawała, a presja, by ją wykonać, wciąż rośnie.
Sesja zaczyna się od figury z Forrester umieszczonej na dużym okręgu: 94% liderów IT nazywa modernizację aplikacji priorytetem inwestycyjnym na najbliższe 6 do 12 miesięcy. Prezentacja na slajdzie odwraca się na rzeczywistość inżyniera pod tym numerem: "Ale musisz zmierzyć się z technicznym długiem." To napięcie jest głównym powodem istnienia tej sesji.

To jest również praca, do której Jeff Fritz, Nish Anil i Hazem El-Hammamy zwrócili się z agentem AI w ramach swojego breakout Build 2026, Wykorzystanie narzędzi AI do nauczania starych aplikacji nowych sztuczek (BRK220). Sesja pokazuje możliwości modernizacyjne GitHub Copilot, które podejmują się zadania, którego inżynierowie się obawiają: czytanie dużej bazy kodu, mapowanie jej zależności, planowanie aktualizacji i bezpieczne refaktorowanie w skali. Oglądaliśmy to z perspektywy warstwy, w której pracujemy, generacji i przetwarzania dokumentów, a najbardziej przydatną nauką jest to, co system agentowy ujawnia, a nie tylko to, co przepisuje.
Ciekawą częścią jest mapa zależności
Część sesji Jeffa to praktyczne spojrzenie programisty .NET: skieruj agenta na prawdziwą starszą aplikację i pozwól mu na rozwikłanie. Analiza bazy kodu i śledzenie przepływów danych ręcznie to krok, który sprawia, że modernizacja jest projektem na kilka kwartałów, ponieważ jest to powolne i łatwo popełnić błąd. Agent, który może przejść przez całe portfolio, zbudować graf zależności i zaznaczyć, co nie przetrwa przeniesienia, skraca ten krok z tygodni do sesji roboczej.

To, co zaznacza, jest ważniejsze niż szybkość. Kiedy agent mapuje zależności, szuka rzeczy, które blokują docelowe środowisko, a konkretną kategorię w starszych aplikacjach .NET wciąż pokazuje: kod zależny od maszyny, na której działa. Klasycznym przykładem jest obsługa dokumentów. Zaskakująca ilość logiki biznesowej legacy generuje PDFy, arkusze kalkulacyjne i pliki Word za pomocą automatyzacji Office, interopu COM lub sterownika drukarki zakładającego komputer stacjonarny. Ten kod działał dobrze na serwerze Windows w 2015 roku. Nie przechodzi do kontenera Linux lub Azure Function, ponieważ nie ma Office do zautomatyzowania i nie ma COM do wywołania. Agent pokaże to jako blokera. Pytanie brzmi, w co to przerobić.
Refaktoryzacja w kierunku zależności, które przetrwają przeniesienie
To jest moment w modernizacji, kiedy decyduje się o warstwie dokumentów, gdzie pasuje nasza praca. Cały impuls przesunięcia polega na wylądowaniu w środowisku, które skalują się i wdrażają czysto: kontenery, serverless, wieloplatformowe CI. Zatem zastępstwo kodu dokumentów zależnego od maszyny musi być zarządzaną biblioteką .NET, która nie ma tych założeń.
Kiedy blokerem jest generacja PDFów, IronPDF renderuje PDFy z HTML w czystym .NET bez Office i bez interopu, więc przepisany kod działa w tym samym kontenerze, do którego przenosi się reszta zmodernizowanej aplikacji. Kiedy jest to automatyzacja arkuszy kalkulacyjnych, IronXL czyta i zapisuje pliki Excel bez Interop Office lub COM, co dokładnie wskazał agent. To samo dotyczy generacji Word z IronWord oraz ścieżek zeskanowanych dokumentów i obrazu do tekstu, które legacy apps często obsługują przy pomocy kruchego narzędziowania, IronOCR utrzymuje ten krok procesowy. Każdy z nich jest docelową refaktoryzacją: agent identyfikuje wywołanie COM lub interopu, a nowy kod to biblioteka, która działa tak samo na każdej platformie.
Powód, dla którego to dobrze współgra z refaktoryzacją agentową, to deterministyczność zamiennika. Agent może przepisać miejsce wywołania z pewnością, gdy nowe API to normalna biblioteka .NET, która zwraca rzeczywisty plik, działa bezgłowo i nie wymaga konfiguracji hosta. Nie ma nic do zainstalowania na docelowym, nie ma nic do licencjonowania na maszynę, nie ma nic uzależnionego od systemu operacyjnego. To jest przymiot, który pozwala na to, aby "refaktoryzacja na dużą skalę" była naprawdę bezpieczna.
Konkretny kształt
Połącz to wszystko i pętla modernizacji wygląda tak. Agent analizuje starszą aplikację i buduje mapę zależności. Wśród blokerów, zaznacza moduł raportowania, który generuje faktury przez automatyzację Office, rodzaj kodu, który nie działa, gdy aplikacja jest uruchamiana w kontenerze. Plan modernizacji przewiduje jego zastąpienie. Agent refaktoryzuje miejsca wywołania do zarządzanej biblioteki, IronPDF dla faktur PDF, IronXL dla eksportu danych, a teraz moduł działa w tym samym kontenerze Linux, co cała reszta. Aplikacja się zmienia, a warstwa dokumentów zmienia się z nią zamiast przykuć ją do Windows.
To jest różnica pomiędzy modernizacją frameworku a modernizacją aplikacji. Modernizacja frameworku jest mechaniczna. Aplikacja naprawdę się zmienia tylko wtedy, gdy zmieniają się jej zależności, a warstwa dokumentów jest jednym z najczęstszych elementów, które ją wstrzymują.
Co dalej?
Sesja wskazuje na dokumentację modernizacji GitHub Copilot i prywatny zapis do wersji przedpremierowej dla centrum zarządzania, książek zasad i możliwości mainframe. Microsoft kontynuuje ten wątek z wirtualnym Dniem Nowoczesności Agentów .NET 16 czerwca, a pełna lista funkcji Build obejmuje wszystkie ogłoszone nowości. Powiązany breakout Modernizacja inteligentnych aplikacji i agentów z .NET, które skalują się wraz z rozwojem (OD801) jest wart zestawienia z tym.
Jeśli planujesz przeprowadzenie modernizacji, warto wiedzieć, które z Twoich blokerów są związane z dokumentami, zanim agent je znajdzie. IronPDF, IronXL, IronWord i IronOCR oferują darmowe wersje próbne, albo pełny zestaw jako Iron Suite, więc możesz mieć gotowy cel refaktoryzacji, gdy mapa zależności powróci. Agent może nauczyć starą aplikację wielu nowych sztuczek. Stworzenie dla niej czystego miejsca do wylądowania jest jednak nadal decyzją inżyniera.

