Omówienie przenoszenia z .NET Framework do platformy .NET
Artykuł
Ten artykuł zawiera omówienie tego, co należy wziąć pod uwagę podczas przenoszenia kodu z .NET Framework do platformy .NET (wcześniej o nazwie .NET Core). Przenoszenie do platformy .NET z .NET Framework dla wielu projektów jest stosunkowo proste. Złożoność projektów określa, ile pracy wykonasz po początkowej migracji plików projektu.
Projekty, w których model aplikacji jest dostępny na platformie .NET (na przykład biblioteki, aplikacje konsolowe i aplikacje klasyczne) zwykle wymagają niewielkiej zmiany. Projekty wymagające nowego modelu aplikacji, takie jak przejście do ASP.NET Core z ASP.NET, wymagają większej liczby pracy. Wiele wzorców ze starego modelu aplikacji ma odpowiedniki, które mogą być używane podczas konwersji.
Windows technologii klasycznych
Wiele aplikacji utworzonych na potrzeby .NET Framework używa technologii klasycznej, takiej jak Windows Forms lub Windows Presentation Foundation (WPF). Zarówno Windows Forms, jak i WPF zostały przeniesione do platformy .NET, ale pozostają one Windows technologii tylko do obsługi.
Przed migracją aplikacji Windows Forms lub WPF należy wziąć pod uwagę następujące zależności:
Project pliki dla platformy .NET używają innego formatu niż .NET Framework.
Projekt może używać interfejsu API, który nie jest dostępny na platformie .NET.
Kontrolki i biblioteki innych firm mogły nie zostać przeniesione do platformy .NET i pozostają dostępne tylko do .NET Framework.
Aplikacje nadal mogą P/Invoke biblioteki natywnych na platformach obsługiwanych przez platformę .NET. Ta technologia nie jest ograniczona do Windows. Jeśli jednak odwołującą się bibliotekę Windows jest specyficzna dla user32.dll lub kernel32.dll, kod działa tylko na Windows. Dla każdej platformy, w której aplikacja ma być uruchomiona, musisz znaleźć wersje specyficzne dla platformy lub ustawić kod na tyle ogólny, aby działał na wszystkich platformach.
Podczas przenoszenia aplikacji z .NET Framework do platformy .NET aplikacja prawdopodobnie użyła biblioteki dostarczonej z .NET Framework. Wiele interfejsów API dostępnych w .NET Framework nie zostało przekierowanych do platformy .NET, ponieważ polegały na technologii specyficznej dla Windows, takiej jak rejestr Windows lub model rysunku GDI+.
Tryb zgodności .NET Framework został wprowadzony w programie .NET Standard 2.0. Ten tryb zgodności umożliwia korzystanie z projektów .NET Standard i .NET 5+ (i .NET Core 3.1) w celu odwołowania się do bibliotek .NET Framework tylko na platformie Windows. Odwoływanie się do bibliotek .NET Framework nie działa dla wszystkich projektów, na przykład jeśli biblioteka używa interfejsów API Windows Presentation Foundation (WPF), ale odblokuje wiele scenariuszy przenoszenia. Aby uzyskać więcej informacji, zobacz Analizowanie zależności do kodu portu z .NET Framework do platformy .NET.
Niedostępne technologie
Istnieje kilka technologii w .NET Framework, które nie istnieją na platformie .NET:
Komunikacja zdalna jest używana do komunikacji między domenami aplikacji, które nie są już obsługiwane. W przypadku prostej komunikacji między procesami należy rozważyć mechanizmy komunikacji między procesami (IPC) jako alternatywę dla komunikacji z komunikacją zdalną, taką jak System.IO.Pipes klasa lub MemoryMappedFile klasa. W przypadku bardziej złożonych scenariuszy należy wziąć pod uwagę struktury, takie jak StreamJsonRpc lub ASP.NET Core (przy użyciu usług gRPC lub RESTful Web API).
Cas to technika piaskownicy obsługiwana przez .NET Framework, ale przestarzała w .NET Framework 4.0. Została zastąpiona przez przezroczystość zabezpieczeń i nie jest obsługiwana na platformie .NET. Zamiast tego należy używać granic zabezpieczeń udostępnianych przez system operacyjny, takich jak wirtualizacja, kontenery lub konta użytkowników.
Podobnie jak w przypadku cas, ta technika piaskownicy nie jest już zalecana w przypadku aplikacji .NET Framework i nie jest obsługiwana na platformie .NET. Zamiast tego należy używać granic zabezpieczeń udostępnianych przez system operacyjny, takich jak wirtualizacja, kontenery lub konta użytkowników.
Platforma .NET (wcześniej znana jako .NET Core) została zaprojektowana tak, aby była międzyplatformowa. Jeśli kod nie zależy od technologii specyficznych dla Windows, może działać na innych platformach, takich jak macOS, Linux i Android. Obejmuje to typy projektów, takie jak:
Biblioteki
Narzędzia oparte na konsoli
Automation
witryny ASP.NET
.NET Framework jest składnikiem tylko Windows. Gdy kod korzysta z technologii lub interfejsów API specyficznych dla Windows, takich jak Windows Forms i Windows Presentation Foundation (WPF), kod może nadal działać na platformie .NET, ale nie będzie uruchamiany w innych systemach operacyjnych.
Istnieje możliwość, że biblioteka lub aplikacja oparta na konsoli może być używana międzyplatformowo bez konieczności zmieniania się. Podczas przenoszenia do platformy .NET warto wziąć pod uwagę i przetestować aplikację na innych platformach.
Przyszłość platformy .NET Standard
.NET Standard to formalna specyfikacja interfejsów API platformy .NET, które są dostępne w wielu implementacjach platformy .NET. Motywacją platformy .NET Standard było ustanowienie większej jednolitości w ekosystemie platformy .NET. Począwszy od platformy .NET 5, przyjęto inne podejście do ustanawiania jednolitości, a to nowe podejście eliminuje potrzebę korzystania z platformy .NET Standard w wielu scenariuszach. Aby uzyskać więcej informacji, zobacz .NET 5 i .NET Standard.
Platforma .NET Standard 2.0 była ostatnią wersją do obsługi .NET Framework.
Narzędzia ułatwiające przenoszenie
Zamiast ręcznie przenosić aplikację z .NET Framework do platformy .NET, możesz użyć różnych narzędzi, aby pomóc zautomatyzować niektóre aspekty migracji. Przenoszenie złożonego projektu jest w sobie złożonym procesem. Te narzędzia mogą pomóc w tej podróży.
Asystent uaktualniania platformy .NET to narzędzie wiersza polecenia, które można uruchamiać w różnych rodzajach aplikacji .NET Framework. Jest ona przeznaczona do ułatwienia uaktualniania aplikacji .NET Framework do platformy .NET 5. Po uruchomieniu narzędzia w większości przypadków aplikacja będzie wymagać większego nakładu pracy w celu ukończenia migracji. Narzędzie zawiera instalację analizatorów, które mogą pomóc w zakończeniu migracji. To narzędzie działa na następujących typach aplikacji .NET Framework:
Windows Forms
WPF
ASP.NET MVC
Konsola
Biblioteki klas
To narzędzie używa innych narzędzi wymienionych w tym artykule i przeprowadzi proces migracji. Aby uzyskać więcej informacji na temat narzędzia, zobacz Omówienie Asystenta uaktualniania platformy .NET.
try-convert
Narzędzie try-convert to globalne narzędzie platformy .NET, które może przekonwertować projekt lub całe rozwiązanie na zestaw .NET SDK, w tym przeniesienie aplikacji klasycznych na platformę .NET 5. Jednak to narzędzie nie jest zalecane, jeśli projekt ma skomplikowany proces kompilacji, taki jak niestandardowe zadania, cele lub importy.
Analizator przenośności platformy .NET to narzędzie, które analizuje zestawy i udostępnia szczegółowy raport na temat interfejsów API platformy .NET, których brakuje, aby aplikacje lub biblioteki były przenośne na określonych docelowych platformach .NET.
Podczas przenoszenia aplikacji na platformę .NET należy wziąć pod uwagę następujące sugestie w kolejności.
✔️ ROZWAŻ użycie Asystenta uaktualniania platformy .NET do migrowania projektów. Mimo że to narzędzie jest w wersji zapoznawczej, automatyzuje większość ręcznych kroków opisanych w tym artykule i zapewnia doskonały punkt wyjścia do kontynuowania ścieżki migracji.
✔️ ROZWAŻ najpierw zbadanie zależności. Zależności muszą być przeznaczone dla platformy .NET 5, .NET Standard lub .NET Core.
✔️ ROZWAŻ uaktualnienie do najnowszego formatu pliku projektu, nawet jeśli nie możesz jeszcze przemienić aplikacji. .NET Framework projekty używają nieaktualnego formatu projektu. Mimo że najnowszy format projektu, znany jako projekty w stylu zestawu SDK, został utworzony dla platformy .NET Core i nie tylko, współpracuje z .NET Framework. Posiadanie pliku projektu w najnowszym formacie daje dobrą podstawę do przenoszenia aplikacji w przyszłości.
✔️ Wykonaj retarget projektu .NET Framework do co najmniej .NET Framework 4.7.2. Zapewnia to dostępność najnowszych alternatyw interfejsów API dla przypadków, w których platforma .NET Standard nie obsługuje istniejących interfejsów API.
✔️ ROZWAŻ użycie platformy .NET 5 zamiast .NET Core 3.1. Chociaż platforma .NET Core 3.1 jest objęta długoterminową obsługą (LTS), platforma .NET 5 jest najnowszą wersją, a platforma .NET 6 zostanie wydana w wersji LTS.
✔️ Docelowy program .NET 5 dla projektów Windows Forms i WPF. Platforma .NET 5 zawiera wiele ulepszeń aplikacji klasycznych.
✔️ ROZWAŻ użycie platformy .NET Standard 2.0, jeśli migrujesz bibliotekę, która może być również używana z projektami .NET Framework. Możesz również wielotargetować bibliotekę, przeznaczoną zarówno dla .NET Framework, jak i .NET Standard.
✔️ Dodaj odwołanie do Windows Microsoft.Windows. Zgodność NuGet pakietu, jeśli po migracji wystąpią błędy braku interfejsów API. Duża część powierzchni interfejsu API .NET Framework jest dostępna dla platformy .NET za pośrednictwem pakietu NuGet.
W tym module dowiesz się, kiedy, dlaczego i jak zmodernizować aplikację platformy ASP.NET Framework, aby ASP.NET Core przy użyciu Asystenta uaktualniania.