.NET Framework-tekniker är inte tillgängliga på .NET

  • Artikel

Flera tekniker som är tillgängliga för .NET Framework-bibliotek är inte tillgängliga för användning med .NET 6+, till exempel appdomäner, fjärrkommunikation och kodåtkomstsäkerhet (CAS). Om dina bibliotek förlitar sig på en eller flera av de tekniker som anges på den här sidan bör du överväga de alternativa metoder som nämns.

Mer information om API-kompatibilitet finns i Icke-bakåtkompatibla ändringar i .NET.

Programdomäner

Programdomäner (AppDomains) isolerar appar från varandra. AppDomains kräver körningsstöd och är resursdyra. Det går inte att skapa fler appdomäner och det finns inga planer på att lägga till den här funktionen i framtiden. Använd separata processer eller containrar som ett alternativ för kodisolering. Om du vill läsa in sammansättningar dynamiskt använder du AssemblyLoadContext klassen .

För att göra kodmigrering från .NET Framework enklare exponerar .NET 6+ en del av API-ytan AppDomain . Vissa AV API:erna fungerar normalt (till exempel AppDomain.UnhandledException), vissa medlemmar gör ingenting (till exempel SetCachePath), och några av dem genererar PlatformNotSupportedException (till exempel CreateDomain). Kontrollera vilka typer du använder mot System.AppDomain referenskällan i GitHub-lagringsplatsen dotnet/runtime. Se till att välja den gren som matchar den implementerade versionen.

Remoting

.NET-fjärrkommunikation stöds inte på .NET 6+. .NET-fjärrkommunikation identifierades som en problematisk arkitektur. Det används för kommunikation mellan programdomäner, som inte längre stöds. Dessutom kräver fjärrkommunikation stöd för körning, vilket är dyrt att underhålla.

För enkel kommunikation mellan processer bör du överväga mekanismer för kommunikation mellan processer (IPC) som ett alternativ till fjärrkommunikation, till exempel System.IO.Pipes klassen eller MemoryMappedFile klassen. För mer komplexa scenarier tillhandahåller StreamJsonRpc-projektet med öppen källkod ett plattformsoberoende .NET Standard-ramverk för fjärrkommunikation som fungerar ovanpå befintliga ström- eller röranslutningar.

Mellan datorer använder du en nätverksbaserad lösning som ett alternativ. Använd helst ett protokoll med låg overhead-oformaterad text, till exempel HTTP. Kestrel-webbservern, som är den webbserver som används av ASP.NET Core, är ett alternativ här. Överväg också att använda System.Net.Sockets för nätverksbaserade scenarier mellan datorer. StreamJsonRpc, som nämnts tidigare, kan användas för JSON- eller binär kommunikation (via MessagePack) via webbsocketar.

Fler meddelandealternativ finns i Utvecklarprojekt med öppen källkod för .NET: Messaging.

Eftersom fjärrkommunikation inte stöds genererar anrop till BeginInvoke() och EndInvoke() på delegerade objekt PlatformNotSupportedException. Mer information finns i Migrera ombud BeginInvoke-anrop för .NET Core.

Kodåtkomstsäkerhet (CAS)

Sandbox-miljö, som förlitar sig på körningen eller ramverket för att begränsa vilka resurser ett hanterat program eller bibliotek använder eller kör, stöds inte på .NET Framework och stöds därför inte heller på .NET 6+. CAS behandlas inte längre som en säkerhetsgräns eftersom det finns för många fall i .NET Framework och körningen där en behörighetshöjning sker. Dessutom gör CAS implementeringen mer komplicerad och har ofta konsekvenser för korrekthetsprestanda för program som inte tänker använda den.

Använd säkerhetsgränser som tillhandahålls av operativsystemet, till exempel virtualisering, containrar eller användarkonton, för att köra processer med minsta möjliga behörighet.

Säkerhetstransparens

På samma sätt som CAS separerar säkerhetstransparensen kod i begränsat läge från säkerhetskritisk kod på ett deklarativt sätt, men stöds inte längre som en säkerhetsgräns. Den här funktionen används mycket av Silverlight.

Om du vill köra processer med minsta möjliga behörighet använder du säkerhetsgränser som tillhandahålls av operativsystemet, till exempel virtualisering, containrar eller användarkonton.

System.EnterpriseServices

System.EnterpriseServices (COM+) stöds inte av .NET 6+.

Arbetsflödesgrund

Windows Workflow Foundation (WF) stöds inte i .NET 6+. Ett alternativ finns i CoreWF.

Dricks

Windows Communication Foundation-servern (WCF) kan användas i .NET 6+ med hjälp av CoreWCF NuGet-paketen. Mer information finns i CoreWCF 1.0 har släppts.

Vissa API:er för reflektionsemitterande stöds inte

.NET 8 och tidigare versioner av .NET (Core) har inte stöd för att spara sammansättningar som genereras av System.Reflection.Emit API:erna och AssemblyBuilder.Save metoden är inte tillgänglig. Dessutom är följande fält i AssemblyBuilderAccess uppräkningen inte tillgängliga:

I .NET 9 implementerades en PersistedAssemblyBuilder och AssemblyBuilder.Save metoden lades till i biblioteket för reflektionsutfärdare. Mer information om hur du använder det här API:et finns i klassen System.Reflection.Emit.AssemblyBuilder.

Mer information finns i dotnet/runtime issue 15704.

Läser in sammansättningar för flera moduler

Sammansättningar som består av flera moduler (OutputType=Module i MSBuild) stöds inte i .NET 6+.

Alternativt kan du överväga att slå samman de enskilda modulerna i en enda sammansättningsfil.

XSLT-skriptblock

XSLT-skriptblock stöds endast i .NET Framework. De stöds inte på .NET 6 eller senare.

Se även