Technologie .NET Framework są niedostępne na platformie .NET
Kilka technologii dostępnych dla bibliotek .NET Framework nie jest dostępnych do użycia z platformą .NET 6 lub nowszym, takich jak domeny aplikacji, komunikacja zdalna i zabezpieczenia dostępu kodu (CAS). Jeśli biblioteki opierają się na co najmniej jednej technologii wymienionej na tej stronie, rozważ wymienione alternatywne podejścia.
Aby uzyskać więcej informacji na temat zgodności interfejsu API, zobacz Zmiany łamiące zgodność na platformie .NET.
Domeny aplikacji
Domeny aplikacji (AppDomains) izolują aplikacje od siebie. Domeny aplikacji wymagają obsługi środowiska uruchomieniowego i są kosztowne dla zasobów. Tworzenie większej liczby domen aplikacji nie jest obsługiwane i nie ma planów dodania tej funkcji w przyszłości. W przypadku izolacji kodu użyj oddzielnych procesów lub kontenerów jako alternatywy. Aby dynamicznie ładować zestawy, użyj klasy AssemblyLoadContext.
Aby ułatwić migrację kodu z programu .NET Framework, platforma .NET 6+ uwidacznia niektóre powierzchnie interfejsu API AppDomain. Niektóre interfejsy API działają normalnie (na przykład AppDomain.UnhandledException), niektóre członkowie nic nie robią (na przykład SetCachePath), a niektóre z nich rzucają PlatformNotSupportedException (na przykład CreateDomain). Sprawdź typy używane względem źródła referencyjnego System.AppDomain w repozytorium GitHub dotnet/runtime. Upewnij się, że wybrano gałąź zgodną z zaimplementowaną wersją.
Komunikacja zdalna
Komunikacja zdalna .NET nie jest obsługiwana w .NET 6+. Zdalna komunikacja platformy .NET została uznana za problematyczną architekturę. Służy do komunikowania się między domenami aplikacji, które nie są już obsługiwane. Ponadto komunikacja zdalna wymaga obsługi środowiska uruchomieniowego, która jest kosztowna do utrzymania.
W przypadku prostej komunikacji między procesami należy rozważyć mechanizmy komunikacji między procesami (IPC) jako alternatywę dla zdalnej komunikacji, taką jak klasa System.IO.Pipes lub klasa MemoryMappedFile. W przypadku bardziej złożonych scenariuszy projekt open source StreamJsonRpc udostępnia międzyplatformową platformę komunikacji wirtualnej .NET Standard, która działa na podstawie istniejących połączeń strumieniowych lub potokowych.
Na różnych maszynach można jako alternatywy użyć rozwiązania opartego na sieci. Najlepiej, należy użyć protokołu zwykłego tekstu niskiego obciążenia, takiego jak HTTP. Serwer internetowy Kestrel, który jest serwerem sieci Web używanym przez ASP.NET Core, jest tutaj opcją. Należy również rozważyć użycie System.Net.Sockets w scenariuszach opartych na sieci, między maszynami. Usługa StreamJsonRpc, o której wspomniano wcześniej, może służyć do komunikacji w formacie JSON lub binarnym (za pośrednictwem pakietu MessagePack) za pośrednictwem gniazd internetowych.
Aby uzyskać więcej opcji obsługi komunikatów, zobacz .NET Open Source Developer Projects: Messaging.
Ponieważ komunikacja zdalna nie jest obsługiwana, wywołania BeginInvoke() i EndInvoke() na obiektach typu delegat zgłoszą PlatformNotSupportedException. Aby uzyskać więcej informacji, zobacz Migrowanie wywołań BeginInvoke dla .NET Core.
Zabezpieczenia dostępu kodu (CAS)
Sandboxing, które opiera się na środowisku uruchomieniowym lub frameworku, aby ograniczyć zasoby używane lub uruchamiane przez zarządzaną aplikację lub bibliotekę, nie jest obsługiwane w .NET Framework, a zatem nie jest również obsługiwane na .NET 6+. Usługa CAS nie jest już traktowana jako granica zabezpieczeń, ponieważ istnieje zbyt wiele przypadków w programie .NET Framework i środowisku uruchomieniowym, w którym występuje podniesienie uprawnień. Ponadto usługa CAS sprawia, że implementacja jest bardziej skomplikowana i często ma implikacje dotyczące wydajności poprawności dla aplikacji, które nie zamierzają jej używać.
Używaj granic zabezpieczeń udostępnianych przez system operacyjny, takich jak wirtualizacja, kontenery lub konta użytkowników, na potrzeby uruchamiania procesów z minimalnym zestawem uprawnień.
Przejrzystość zabezpieczeń
Podobnie jak w przypadku cas, przezroczystość zabezpieczeń oddziela kod w trybie piaskownicy od kodu krytycznego pod względem zabezpieczeń w sposób deklaratywny, ale nie jest już obsługiwany jako granica zabezpieczeń. Ta funkcja jest intensywnie używana przez program Silverlight.
Aby uruchamiać procesy z najmniejszym zestawem uprawnień, należy użyć 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 przez platformę .NET 6+.
Podstawy przepływu pracy
Program Windows Workflow Foundation (WF) nie jest obsługiwany na platformie .NET 6+. Aby uzyskać alternatywę, zobacz CoreWF.
Napiwek
Serwer Windows Communication Foundation (WCF) może być używany na platformie .NET 6+ przy użyciu pakietów NuGet CoreWCF. Aby uzyskać więcej informacji, zobacz CoreWCF 1.0 został wydany.
Niektóre interfejsy API emisji odbicia nie są obsługiwane
Platforma .NET 8 i starsze wersje platformy .NET (Core) nie obsługują zapisywania zestawów generowanych przez interfejsy API System.Reflection.Emit, a metoda AssemblyBuilder.Save jest niedostępna. Ponadto następujące pola wyliczenia AssemblyBuilderAccess nie są dostępne:
Na platformie .NET 9 zaimplementowano PersistedAssemblyBuilder, a metoda AssemblyBuilder.Save została dodana z powrotem do biblioteki emitowania odbicia. Aby dowiedzieć się więcej o sposobie korzystania z tego API, zobacz klasę System.Reflection.Emit.PersistedAssemblyBuilder.
Aby uzyskać więcej informacji na temat różnych implementacji AssemblyBuilder na platformie .NET, zobacz System.Reflection.Emit.AssemblyBuilder, klasa.
Ładowanie zestawów z wieloma modułami
Zestawy składające się z wielu modułów (OutputType=Module w programie MSBuild) nie są obsługiwane w programie .NET 6+.
Alternatywnie, rozważ scalenie poszczególnych modułów do pojedynczego pliku zestawu.
Bloki skryptów XSLT
Bloki skryptów XSLT są obsługiwane tylko w programie .NET Framework. Nie są one obsługiwane na platformie .NET 6 lub nowszym.
