Tecnologie .NET Framework non disponibili in .NET
Diverse tecnologie disponibili per le librerie .NET Framework non sono utilizzabili con .NET 6+, come i domini applicativi, il remoting e la sicurezza dell'accesso al codice (CAS). Se le librerie si basano su una o più tecnologie elencate in questa pagina, prendere in considerazione gli approcci alternativi indicati.
Per altre informazioni sulla compatibilità delle API, vedere Modifiche di rilievo in .NET.
Domini delle applicazioni
I domini applicazione (AppDomains) isolano le app l'una dall'altra. AppDomains richiedono il supporto di runtime e consumano molte risorse. La creazione di altri domini app non è supportata e non sono previsti piani per aggiungere questa funzionalità in futuro. Per l'isolamento del codice, usare processi o contenitori separati come alternativa. Per caricare in modo dinamico gli assembly, usare la classe AssemblyLoadContext.
Per semplificare la migrazione del codice da .NET Framework, .NET 6+ espone alcune delle AppDomain superficie dell'API. Alcune delle API funzionano normalmente (ad esempio, AppDomain.UnhandledException), alcuni membri non eseguono alcuna operazione (ad esempio, SetCachePath) e alcuni di essi generano PlatformNotSupportedException (ad esempio, CreateDomain). Controllare i tipi usati per l'origine di riferimento System.AppDomain nel repository GitHub dotnet/runtime. Assicurarsi di selezionare il ramo corrispondente alla versione implementata.
Comunicazione remota
.NET Remoting non è supportato in .NET 6+. La comunicazione remota .NET è stata identificata come un'architettura problematica. Viene usato per comunicare tra domini applicazione, che non sono più supportati. Inoltre, la comunicazione remota richiede il supporto del runtime, che è costoso da gestire.
Per una comunicazione semplice tra processi, si possono considerare i meccanismi di comunicazione tra processi (IPC) come alternativa alla comunicazione remota, ad esempio la classe System.IO.Pipes o la classe MemoryMappedFile. Per scenari più complessi, il progetto StreamJsonRpc open source fornisce un framework di comunicazione remota .NET Standard multipiattaforma che funziona su connessioni di flusso o pipe esistenti.
Su tutte le macchine, usa una soluzione basata sulla rete come alternativa. Preferibilmente, usare un protocollo di testo normale a basso sovraccarico, ad esempio HTTP. Il server Web Kestrel, che è il server Web usato da ASP.NET Core, è un'opzione qui. Prendere in considerazione anche l'uso di System.Net.Sockets per scenari tra computer basati sulla rete. StreamJsonRpc, menzionato in precedenza, può essere usato per la comunicazione JSON o binaria (tramite MessagePack) tramite web socket.
Per altre opzioni di messaggistica, vedere Progetti di sviluppo open source .NET: Messaggistica.
Poiché la comunicazione remota non è supportata, le chiamate a BeginInvoke() e EndInvoke() sugli oggetti delegati genereranno PlatformNotSupportedException. Per ulteriori informazioni, vedere Migrazione delle chiamate BeginInvoke del delegate per .NET Core.
Sicurezza dell'accesso al codice
Sandboxing, che si basa sul runtime o sul framework per vincolare le risorse usate da un'applicazione gestita o da una libreria, non è supportato in .NET Framework e pertanto non è supportato anche in .NET 6+. Cas non viene più considerato come limite di sicurezza, perché in .NET Framework sono presenti troppi casi e il runtime in cui si verifica un'elevazione dei privilegi. Inoltre, cas rende l'implementazione più complicata e spesso ha implicazioni di correttezza delle prestazioni per le applicazioni che non intendono usarla.
Usare i limiti di sicurezza forniti dal sistema operativo, ad esempio la virtualizzazione, i contenitori o gli account utente, per l'esecuzione di processi con il set minimo di privilegi.
Trasparenza della sicurezza
Analogamente a CAS, la trasparenza della sicurezza separa il codice in modalità sandbox dal codice critico per la sicurezza in modo dichiarativo, ma è non più supportato come limite di sicurezza. Questa funzionalità è ampiamente usata da Silverlight.
Per eseguire i processi con il minor set di privilegi, usare i limiti di sicurezza forniti dal sistema operativo, ad esempio la virtualizzazione, i contenitori o gli account utente.
System.EnterpriseServices
System.EnterpriseServices (COM+) non è supportato da .NET 6+.
Workflow Foundation
Windows Workflow Foundation (WF) non è supportato in .NET 6+. Per un'alternativa, vedere CoreWF.
Mancia
Il server Windows Communication Foundation (WCF) può essere usato in .NET 6+ usando i pacchetti NuGet CoreWCF. Per altre informazioni, vedere CoreWCF 1.0 è stato rilasciato.
Alcune API di reflection emit non sono supportate
.NET 8 e versioni precedenti di .NET (Core) non supportano il salvataggio di assembly generati dalle API System.Reflection.Emit e il metodo AssemblyBuilder.Save non è disponibile. Inoltre, i campi seguenti dell'enumerazione AssemblyBuilderAccess non sono disponibili:
In .NET 9 è stato implementato un PersistedAssemblyBuilder e il metodo AssemblyBuilder.Save è stato nuovamente aggiunto alla libreria reflection emit. Per altre informazioni su come usare questa API, vedere classe System.Reflection.Emit.PersistedAssemblyBuilder.
Per altre informazioni sulle diverse implementazioni di AssemblyBuilder in .NET, vedere classe System.Reflection.Emit.AssemblyBuilder.
Caricamento di assembly multimodulo
Gli assembly costituiti da più moduli (OutputType=Module in MSBuild) non sono supportati in .NET 6+.
In alternativa, è consigliabile unire i singoli moduli in un singolo file di assembly.
Blocchi di script XSLT
I blocchi di script XSLT sono supportati solo in .NET Framework. Non sono supportati in .NET 6 o versioni successive.
