AWS AWS Transform .NET migration Azure

AWS Transform .NET: konwersja zatrzymuje się lub zostawia TODO - nieobsługiwany kod i błędy zależności

Rozwiązanie sytuacji, gdy AWS Transform dla .NET zatrzymuje się na zależności, której nie potrafi przenieść, albo kończy z komentarzami TODO, zaślepkami i plikiem Next Steps: odczytanie tego, co oznaczył, zrozumienie znanych nieobsługiwanych przypadków i dokończenie części, które agent zostawia Tobie.

Jerzy Kopaczewski · 2026-10-20

AWS Transform dla .NET albo zatrzymuje się w trakcie, zgłaszając, że nie potrafi przenieść zależności, albo kończy, ale zostawia komentarze TODO, zaślepione metody i plik markdown Next Steps. To nie jest błąd, to agent mówi Ci, którego kodu nie dało się przekonwertować automatycznie. Ten runbook pokazuje, jak odczytać to, co oznaczył, które przypadki są znane jako nieobsługiwane i jak domknąć lukę.

Ten runbook to praktyczne uzupełnienie naszego przewodnika o migracji Azure do AWS z AWS Transform, który opisuje, co narzędzie automatyzuje, a czego nie. Po pomoc w przeprowadzeniu migracji od początku do końca umów konsultację.

Objawy

Przebieg albo zatrzymuje się na zależności, albo kończy z lukami, które musisz wypełnić.

# 1. Transformacja zatrzymuje się na zależności, której nie potrafi przenieść
AWS Transform stopped: unable to port dependency <ProjectName>.
See the error details for the dependency that caused the failure.

# 2. Kończy, ale z nieprzekonwertowanym kodem oznaczonym w miejscu
// TODO: AWS Transform could not convert this code automatically.
// Manual migration required.

# 3. Powstaje plik Next Steps z listą pracy ręcznej
# NextSteps.md  ->  "The following items require manual migration"

Obserwowalny skutek:

Transformacja kończy się, ale przeniesione rozwiązanie nie buduje się, dopóki TODO nie zostaną rozwiązane
Pojedyncza niskopoziomowa zależność zatrzymuje cały przebieg (agent przenosi od dołu, najpierw najniższą zależność)
Projekty UI lub interop natywny są oznaczane jako nieprzeniesione

Przyczyna

AWS Transform przenosi aplikację od zależności najniższego poziomu w górę i celowo zatrzymuje się lub zaślepia, zamiast zgadywać, gdy napotka kod, którego nie potrafi przekonwertować.

Działa od dołu i zatrzymuje się na zależności, której nie potrafi przenieść. Jeśli niskopoziomowy projekt nie da się przenieść, agent zatrzymuje transformację i zgłasza, co ją spowodowało, bo wszystko powyżej od niego zależy. Jedna blokująca zależność potrafi zatrzymać cały przebieg.
Część kodu jest znana jako nieobsługiwana. AWS Transform nie przenosi komponentów UI Blazor, bibliotek Win32 DLL, które nie mają odpowiedników zgodnych z core, ani repozytoriów bez rozwiązań .NET. Kod, który nie ma odpowiednika na AWS, zostaje jako komentarze TODO, kod zaślepiony albo wpisy w wygenerowanym pliku Next Steps.
Ograniczenia środowiska i wersji. Agent .NET wymaga maszyny deweloperskiej z Windows, a narzędzia bazodanowe wspierają tylko określone wersje (Entity Framework 6.3-6.5 oraz EF Core 1.0-10.0). Działanie poza tymi ograniczeniami daje błędy, które wyglądają jak błędy konwersji, a są naprawdę wymaganiami wstępnymi.

Rozwiązanie

Krok 1: Najpierw przeczytaj plik Next Steps i znaczniki TODO

Agent już powiedział Ci, czego nie potrafił zrobić. Zbierz to, zanim dotkniesz kodu.

# Znajdź wygenerowany plik Next Steps w przeniesionym wyjściu
find . -iname "NextSteps*.md" -o -iname "README*transform*.md"

# Wylistuj każde TODO, które agent zostawił, z plikiem i linią
grep -rn "AWS Transform could not convert" --include="*.cs" .
grep -rn "TODO: Manual migration" --include="*.cs" .

To jest Twoja faktyczna lista zadań. Nie zaczynaj ręcznego przepisywania, zanim jej nie przeczytasz, bo większość pozostałego wysiłku jest tu wyliczona.

Krok 2: Jeśli przebieg się zatrzymał, wyizoluj blokującą zależność

Zatrzymanie oznacza, że jednej zależności nie dało się przenieść. Ponieważ agent działa od dołu, napraw najpierw najniższy niedziałający projekt i uruchom ponownie.

# Ustal kolejność zależności projektów (najpierw najniższy poziom)
dotnet list YourSolution.sln reference

# Sprawdź zależność wskazaną w błędzie pod kątem znanych nieobsługiwanych przypadków:
#  - komponenty UI Blazor
#  - DLL Win32 / interop natywny bez bibliotek zgodnych z core
#  - odwołania do pakietów Azure SDK bez bezpośredniego odpowiednika na AWS
grep -rln "Microsoft.AspNetCore.Components" --include="*.csproj" .
grep -rln "Azure\." --include="*.csproj" .

Rozwiąż lub wyklucz blokujący projekt (zobacz krok 3), a potem uruchom transformację ponownie, aby port od dołu mógł przejść dalej.

Krok 3: Potraktuj znane nieobsługiwane przypadki świadomie

Każda nieobsługiwana kategoria ma standardową ścieżkę. Nie oczekuj, że agent je przekonwertuje.

Komponenty UI Blazor nie są przenoszone. Przenieś warstwę UI osobno albo zachowaj ją i przekieruj tylko backend. AWS Transform potrafi przenieść UI ASP.NET do frameworków zgodnych z ASP.NET Core, ale sam Blazor jest poza zakresem.
DLL Win32 / natywne bez bibliotek zgodnych z core potrzebują zarządzanego zamiennika lub przeróbki tego interopu, zanim projekt ruszy na Linuksie.
Wywołania Azure SDK bez odpowiednika na AWS są zaślepiane lub oznaczane TODO. Zamień je na AWS SDK ręcznie, na przykład klient Azure Blob na klienta S3, Azure Service Bus na SQS/SNS, bo to właśnie praca mapowania usług, której agent nie potrafi wywnioskować.

Krok 4: Potwierdź wymagania wstępne, zanim obwinisz konwersję

Wyklucz ograniczenia środowiska, które podszywają się pod błędy konwersji.

# Agent .NET wymaga maszyny deweloperskiej z Windows
# Potwierdź, że Twoja wersja EF jest w obsługiwanym zakresie
#   Entity Framework 6.3-6.5, albo EF Core 1.0-10.0
dotnet list package | grep -iE "EntityFramework|Microsoft.EntityFrameworkCore"

Jeśli wersja EF jest poza obsługiwanym zakresem, najpierw ją wyrównaj, bo od niej zależy konwersja kodu dostępu do danych.

Walidacja

Potwierdź, że przeniesione rozwiązanie buduje się, a oznaczona praca jest domknięta.

# 1. Nie zostały żadne nierozwiązane TODO od AWS Transform
grep -rc "AWS Transform could not convert" --include="*.cs" . | grep -v ":0$"
# Oczekiwane: brak wyniku (każde oznaczone TODO rozwiązane)

# 2. Przeniesione rozwiązanie buduje się na docelowej platformie
dotnet build YourSolution.sln -c Release
# Oczekiwane: Build succeeded, 0 Error(s)

# 3. Aplikacja celuje w nowoczesny runtime zdolny do pracy na Linuksie
grep -rh "<TargetFramework>" --include="*.csproj" . | sort -u
# Oczekiwane: net8.0 / net9.0 (nie net48 / netframework)

AWS Transform wykonuje mechaniczną większość portu .NET, ale części, które oznacza (UI Blazor, interop natywny i mapowanie usług Azure na AWS), to dokładnie te decyzje architektoniczne, które wymagają człowieka. Potraktuj plik Next Steps jako realny zakres drugiej połowy migracji, a nie dodatek na później.

Migrujesz .NET z Azure do AWS?

Umów bezpłatną rozmowę na 30 minut. Przeprowadzamy migracje AWS Transform od początku do końca, domykamy ręczną pracę mapowania usług, którą narzędzie oznacza, i doprowadzamy Twoje aplikacje .NET do budowania na Linuksie.

Umów rozmowę

Powiązane

Migracja Azure do AWS z AWS Transform: konwersja kodu .NET - co narzędzie automatyzuje, a co zostawia Tobie
Kalkulator kosztów migracji do AWS: realne liczby wg wielkości firmy - budżetowanie migracji wokół pracy ręcznej
Dokumentacja AWS Transform dla .NET