.NET Framework-Technologien sind auf .NET nicht verfügbar
Mehrere Technologien, die für .NET Framework-Bibliotheken verfügbar sind, stehen nicht zur Verwendung mit .NET 6+ zur Verfügung, z. B. App-Domänen, Remoting und Codezugriffssicherheit (Code Access Security, CAS). Wenn Ihre Bibliotheken auf eine oder mehrere der auf dieser Seite aufgeführten Technologien angewiesen sind, sollten Sie die auf dieser Seite erwähnten alternativen Ansätze berücksichtigen.
Weitere Informationen zur API-Kompatibilität finden Sie unter Breaking changes in .NET.
Anwendungsdomänen
Anwendungsdomänen (AppDomains) isolieren Apps voneinander. AppDomains erfordern Laufzeitunterstützung und sind ressourcenintensiv. Das Erstellen weiterer App-Domänen wird nicht unterstützt, und es gibt keine Pläne, diese Funktion in Zukunft hinzuzufügen. Verwenden Sie für die Codeisolation separate Prozesse oder Container als Alternative. Um Assemblys dynamisch zu laden, verwenden Sie die AssemblyLoadContext Klasse.
Um die Codemigration von .NET Framework zu vereinfachen, macht .NET 6+ einige der AppDomain API-Oberfläche verfügbar. Einige der APIs funktionieren normalerweise (z. B. AppDomain.UnhandledException), einige Member tun nichts (z. B. SetCachePath), und einige von ihnen werfen PlatformNotSupportedException (z. B. CreateDomain). Prüfen Sie die von Ihnen verwendeten Typen anhand der System.AppDomainReferenzquelle im dotnet/runtime GitHub Repository. Stellen Sie sicher, dass Sie den Branch auswählen, der Ihrer implementierten Version entspricht.
Remoting
.NET Remoting wird unter .NET 6+ nicht unterstützt. Das .NET-Remoting wurde als eine problematische Architektur identifiziert. Sie wird für die Kommunikation über Anwendungsdomänen hinweg verwendet, die nicht mehr unterstützt werden. Darüber hinaus erfordert Remoting die Runtimeunterstützung, deren Wartung teuer ist.
Für einfache Kommunikation zwischen Prozessen sollten Sie die Mechanismen prozessübergreifender Kommunikation (Inter-Process Communication, IPC) als Alternative zu Remoting berücksichtigen, z. B. die Klassen System.IO.Pipes oder MemoryMappedFile. Für komplexere Szenarien stellt das Open-Source-StreamJsonRpc-Projekt ein plattformübergreifendes .NET-Standard-Remotingframework bereit, das auf vorhandenen Stream- oder Pipe-Verbindungen funktioniert.
Verwenden Sie auf allen Computern eine netzwerkbasierte Lösung als Alternative. Verwenden Sie vorzugsweise ein schlichtes und ressourcenschonendes Textprotokoll, wie z. B. HTTP. Der Kestrel-Webserver, der von ASP.NET Core verwendete Webserver ist, ist hier eine Option. Erwägen Sie außerdem die Verwendung von System.Net.Sockets für netzwerkbasierte, computerübergreifende Szenarien. StreamJsonRpc, bereits erwähnt, kann für die JSON- oder binäre Kommunikation (über MessagePack) über Websockets verwendet werden.
Weitere Messagingoptionen finden Sie unter .NET Open Source Developer Projects: Messaging.
Da Remoting nicht unterstützt wird, werden Aufrufe von BeginInvoke() und EndInvoke() für Delegatobjekte ausgelöst PlatformNotSupportedException. Weitere Informationen finden Sie unter Migrieren von Delegaten für BeginInvoke-Aufrufe für .NET Core.
Codezugriffssicherheit (Code Access Security, CAS)
Das Verwenden einer Sandbox, das sich auf die Runtime oder das Framework verlässt, um einzuschränken, welche Ressourcen eine verwaltete Anwendung oder Bibliothek verwendet oder ausführt, wird in .NET Framework nicht unterstützt. Daher wird es auch in .NET 6 und höher nicht unterstützt. CAS wird nicht mehr als Sicherheitsgrenze behandelt, da es zu viele Fälle in .NET Framework und der Laufzeit gibt, in denen eine Rechteerweiterung auftritt. Darüber hinaus macht CAS die Implementierung komplizierter und hat häufig Auswirkungen auf die Korrektheitsleistung für Anwendungen, die sie nicht verwenden möchten.
Verwenden Sie Sicherheitsgrenzen, die vom Betriebssystem bereitgestellt werden, z. B. Virtualisierung, Container oder Benutzerkonten, für ausgeführte Prozesse mit den mindesten Berechtigungen.
Sicherheitstransparenz
Ähnlich wie CAS trennt die Sicherheitstransparenz den Sandboxcode von sicherheitsrelevantem Code in einer deklarativen Weise, aber sie wird nicht mehr als Sicherheitsgrenze unterstützt. Dieses Feature wird von Silverlight stark verwendet.
Um Prozesse mit den geringsten Berechtigungen auszuführen, verwenden Sie vom Betriebssystem bereitgestellte Sicherheitsgrenzen, z. B. Virtualisierung, Container oder Benutzerkonten.
System.EnterpriseServices
System.EnterpriseServices (COM+) wird von .NET 6+ nicht unterstützt.
Workflow Foundation
Windows Workflow Foundation (WF) wird in .NET 6+ nicht unterstützt. Eine Alternative finden Sie unter CoreWF.
Tipp
Windows Communication Foundation (WCF)-Server kann in .NET 6+ mithilfe der CoreWCF NuGet-Paketeverwendet werden. Weitere Informationen finden Sie unter . CoreWCF 1.0 wurde veröffentlicht.
Einige Spiegelungs-Emitt-APIs werden nicht unterstützt.
.NET 8 und frühere Versionen von .NET (Core) unterstützen nicht das Speichern von Assemblies, die von den System.Reflection.Emit-APIs generiert werden, und die AssemblyBuilder.Save-Methode ist nicht verfügbar. Darüber hinaus sind die folgenden Felder der AssemblyBuilderAccess Enumeration nicht verfügbar:
In .NET 9 wurde ein PersistedAssemblyBuilder implementiert, und die AssemblyBuilder.Save-Methode wurde wieder zur Bibliothek für die Reflexionsausgabe hinzugefügt. Weitere Informationen zur Verwendung dieser API finden Sie unter System.Reflection.Emit.PersistedAssemblyBuilder-Klasse.
Weitere Informationen zu den verschiedenen AssemblyBuilder-Implementierungen in .NET finden Sie unter System.Reflection.Emit.AssemblyBuilder-Klasse.
Laden von Baugruppen mit mehreren Modulen
Assemblys, die aus mehreren Modulen (OutputType=Module in MSBuild) bestehen, werden in .NET 6+ nicht unterstützt.
Alternativ können Sie die einzelnen Module in einer einzigen Assemblydatei zusammenführen.
XSLT-Skriptblöcke
XSLT-Skriptblöcke werden nur in .NET Framework unterstützt. Sie werden auf .NET 6 oder höher nicht unterstützt.
