Tecnologie di .NET Framework non disponibili in .NET

  • Articolo

Diverse tecnologie disponibili per le librerie .NET Framework non sono disponibili per l'uso con .NET 6+, ad esempio domini app, comunicazione remota e sicurezza dell'accesso al codice. 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 che causano un'interruzione in .NET.

Domini applicazione

I domini applicazione (AppDomain) consentono di isolare le app l'una dall'altra. I domini applicazione richiedono il supporto di runtime e sono costosi a livello di risorse. La creazione di altri domini applicazione non è supportata e non è prevista l'aggiunta di questa funzionalità in futuro. Per l'isolamento del codice, è consigliabile usare come alternativa processi e/o contenitori separati. Per caricare in modo dinamico gli assembly, usare la classe AssemblyLoadContext.

Per semplificare la migrazione di codice da .NET Framework, .NET 6+ espone parte della superficie dell'API AppDomain. Alcune delle API funzionano normalmente, (ad esempio AppDomain.UnhandledException), alcuni membri non eseguono alcuna operazione (ad esempio, SetCachePath) e alcuni generano PlatformNotSupportedException (ad esempio, CreateDomain). Controllare i tipi usati per l'origine di riferimento System.AppDomain nel repository dotnet/runtime di GitHub. Assicurarsi di selezionare il ramo corrispondente alla versione implementata.

Gestione remota

.NET Remoting non è supportato in .NET 6+. L'architettura di .NET Remoting è stata identificata come problematica. Viene usata per comunicare tra domini applicazione, che non sono più supportati. La comunicazione remota richiede inoltre il supporto di runtime, che è costoso da gestire.

Per semplici comunicazioni tra processi, è possibile usare i meccanismi di comunicazione tra processi (IPC, Inter-Process Communication) in alternativa alla comunicazione remota, come la classe System.IO.Pipes o MemoryMappedFile. Per scenari più complessi, il progetto open source StreamJsonRpc fornisce un framework di comunicazione remota .NET Standard multipiattaforma che funziona su connessioni di flusso o pipe esistenti.

Per le comunicazioni tra computer, usare una soluzione basata su rete in alternativa. Preferibilmente, usare un protocollo di testo normale con basso overhead, come HTTP. Il server Web Kestrel, ovvero il server Web usato da ASP.NET Core, rappresenta un'opzione praticabile in questo caso. Valutare anche l'uso di System.Net.Sockets per gli scenari basati sulla rete per le comunicazioni tra computer. StreamJsonRpc, menzionato in precedenza, può essere usato per la comunicazione JSON o binaria (tramite MessagePack) tramite Web Socket.

Per informazioni su 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 altre informazioni, vedere Migrazione di chiamate BeginInvoke delegate per .NET Core.

Sicurezza dall'accesso di codice (CAS, Code Access Security)

Il sandboxing, che si basa sul runtime o sul framework per vincolare le risorse usate o eseguite da un'applicazione gestita o una libreria, non è supportato in .NET Framework e pertanto non è supportato neanche in .NET 6+. La sicurezza dall'accesso di codice non viene più considerata come un limite di sicurezza perché esistono troppi casi in .NET Framework e nel runtime in cui si verifica un'elevazione dei privilegi. La sicurezza dall'accesso di codice, inoltre, rende l'implementazione più complicata e spesso ha implicazioni a livello di prestazioni della correttezza per le applicazioni che non intendono usare questo meccanismo di sicurezza.

Usare i limiti di sicurezza forniti dal sistema operativo, ad esempio la virtualizzazione, i contenitori o gli account utente, per eseguire i processi con il set di privilegi minimo.

Trasparenza della sicurezza

Analogamente alla sicurezza dall'accesso di codice, la trasparenza della sicurezza separa il codice in modalità sandbox dal codice critico per la sicurezza in modalità dichiarativa, ma non è più supportata come limite di sicurezza. Questa funzionalità è ampiamente usata da Silverlight.

Per eseguire i processi con il set di privilegi più ridotto possibile, 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 in .NET 6+.

Workflow Foundation

Windows Workflow Foundation (WF) non è supportato in .NET 6+. Per un'alternativa, vedere CoreWF.

Suggerimento

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 generate dalle API di System.Reflection.Emit e il metodo AssemblyBuilder.Save non è disponibile. I campi seguenti dell'enumerazione AssemblyBuilderAccess non sono inoltre disponibili:

In .NET 9 è stato implementato un PersistedAssemblyBuilder e il metodo AssemblyBuilder.Save è stato aggiunto di nuovo alla libreria reflection emit. Per altre informazioni su come usare questa API, vedere Classe System.Reflection.Emit.AssemblyBuilder.

Per altre informazioni, vedere Problema 15704 per dotnet/runtime.

Caricamento di assembly con più moduli

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.

Vedi anche