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:

  1. Project pliki dla platformy .NET używają innego formatu niż .NET Framework.
  2. Projekt może używać interfejsu API, który nie jest dostępny na platformie .NET.
  3. Kontrolki i biblioteki innych firm mogły nie zostać przeniesione do platformy .NET i pozostają dostępne tylko do .NET Framework.
  4. Projekt korzysta z technologii, która nie jest już dostępna na platformie .NET.

Platforma .NET korzysta z wersji open source Windows Forms i WPF oraz obejmuje ulepszenia w .NET Framework.

Aby uzyskać samouczki dotyczące migracji aplikacji klasycznej do platformy .NET 6, zobacz jeden z następujących artykułów:

interfejsy API specyficzne dla Windows

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+.

Pakiet zgodności Windows udostępnia dużą część powierzchni interfejsu API .NET Framework na platformie .NET i jest dostarczany za pośrednictwem witryny Microsoft.Windows. Pakiet NuGet zgodności.

Aby uzyskać więcej informacji, zobacz Use the Windows Compatibility Pack to port code to .NET (Używanie pakietu zgodności Windows do portu kodu na platformie .NET).

.NET Framework tryb zgodności

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:

  • Domeny aplikacji

    Tworzenie dodatkowych domen aplikacji nie jest obsługiwane. W przypadku izolacji kodu użyj oddzielnych procesów lub kontenerów jako alternatywy.

  • Usług zdalnych

    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).

  • Zabezpieczenia dostępu do kodu (CAS)

    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.

  • Przezroczystość zabezpieczeń

    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.

  • System.EnterpriseServices

    System.EnterpriseServices (COM+) nie jest obsługiwana na platformie .NET.

  • Program Windows Workflow Foundation (WF)

    Program WF nie jest obsługiwany na platformie .NET 5+ (w tym .NET Core). Aby uzyskać alternatywę, zobacz CoreWF.

Aby uzyskać więcej informacji na temat tych nieobsługiwanych technologii, zobacz .NET Framework technologie niedostępne na platformie .NET Core i .NET 5+.

Wiele platform

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.

Nawet jeśli używasz narzędzia ułatwiającego przenoszenie aplikacji, zapoznaj się z sekcją Zagadnienia dotyczące przenoszenia w tym artykule.

Asystent uaktualnienia platformy .NET

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.

Aby uzyskać więcej informacji, zobacz repozytorium try-convert GitHub.

Analizator przenośności platformy .NET

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.

Aby użyć analizatora portability platformy .NET w Visual Studio, zainstaluj rozszerzenie z witryny Marketplace.

Aby uzyskać więcej informacji, zobacz Analizator portability platformy .NET.

Analizator zgodności platformy

Analizator zgodności platformy analizuje, czy używasz interfejsu API, który będzie zgłaszany PlatformNotSupportedException w czasie wykonywania. Chociaż nie jest to powszechne, jeśli przenosisz się z .NET Framework 4.7.2 lub nowszej, warto sprawdzić. Aby uzyskać więcej informacji na temat interfejsów API zgłaszających wyjątki na platformie .NET, zobacz Interfejsy API, które zawsze zgłaszają wyjątki na platformie .NET Core.

Aby uzyskać więcej informacji, zobacz Analizator zgodności platformy.

Zagadnienia dotyczące przenoszenia

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.

✔️ Przeprowadź migrację z pliku NuGetpackages.config do PackageReference ustawień w pliku projektu. Użyj Visual Studio, aby przekonwertować package.config plik.

✔️ 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.

Zobacz też