Technologies .NET Framework indisponibles sur .NET
Plusieurs technologies disponibles pour les bibliothèques .NET Framework ne sont pas disponibles pour une utilisation avec .NET 6+, telles que les domaines d’application, la communication à distance et la sécurité d’accès au code (CAS). Si vos bibliothèques s’appuient sur une ou plusieurs des technologies répertoriées sur cette page, tenez compte des autres approches mentionnées.
Pour plus d’informations sur la compatibilité des API, consultez Changements cassants dans .NET.
Domaines d’application
Les domaines d’application (AppDomains) isolent les applications les unes des autres. Les domaines d’application nécessitent la prise en charge du runtime et sont coûteux en ressources. La création de domaines d’application supplémentaires n’est pas prise en charge et il n’existe aucun plan pour ajouter cette fonctionnalité à l’avenir. Pour l’isolation du code, utilisez des processus ou des conteneurs distincts comme alternative. Pour charger dynamiquement des assemblys, utilisez la classe AssemblyLoadContext.
Pour faciliter la migration du code à partir de .NET Framework, .NET 6+ expose une partie de la surface d’API AppDomain. Certaines des API fonctionnent normalement (par exemple, AppDomain.UnhandledException), certains membres ne font rien (par exemple, SetCachePath), et certains d’entre eux lèvent PlatformNotSupportedException (par exemple, CreateDomain). Vérifiez les types que vous utilisez par rapport à la source de référence System.AppDomain dans le référentiel GitHub dotnet/runtime . Veillez à sélectionner la branche qui correspond à votre version implémentée.
Communication à distance
La communication à distance .NET n’est pas prise en charge sur .NET 6+. Le remoting .NET a été identifié comme architecture problématique. Il est utilisé pour communiquer entre les domaines d’application, qui ne sont plus pris en charge. Par ailleurs, le remoting requiert la prise en charge du runtime, dont la maintenance est coûteuse.
Pour simplifier la communication entre les processus, envisagez de mettre en place des mécanismes de communication interprocessus (IPC) à la place du remoting (par exemple, la classe System.IO.Pipes ou MemoryMappedFile). Pour les scénarios plus complexes, le projet open source StreamJsonRpc fournit un framework de remoting standard .NET multiplateforme qui fonctionne sur des connexions de flux ou de canal existantes.
Sur plusieurs ordinateurs, utilisez une solution basée sur le réseau comme alternative. De préférence, utilisez un protocole de texte brut à faible charge, tel que HTTP. Le serveur web Kestrel, qui est le serveur web utilisé par ASP.NET Core, est une option ici. Envisagez également d’utiliser System.Net.Sockets pour les scénarios inter-ordinateurs basés sur le réseau. StreamJsonRpc, mentionné précédemment, peut être utilisé pour la communication JSON ou binaire (via MessagePack) sur des sockets web.
Pour plus d'options de messagerie, consultez les projets de développement .NET open source : Messagerie.
Étant donné que la liaison à distance n'est pas prise en charge, les appels à BeginInvoke() et EndInvoke() sur les objets délégués généreront une PlatformNotSupportedException. Pour plus d’informations, consultez Migration des appels BeginInvoke délégués pour .NET Core.
Sécurité de l’accès au code (CAS)
Sandboxing, qui s’appuie sur le runtime ou l’infrastructure pour limiter les ressources qu’une application managée ou une bibliothèque utilise ou exécute, n’est pas prise en charge sur .NET Framework et n’est donc pas prise en charge sur .NET 6+. Le cas n’est plus traité comme une limite de sécurité, car il existe trop de cas dans .NET Framework et dans le runtime où une élévation de privilèges se produit. En outre, le CAS rend l'implémentation plus complexe et a souvent des conséquences en termes de correctitude et de performance pour les applications qui ne prévoient pas de l'utiliser.
Utilisez les limites de sécurité fournies par le système d’exploitation, telles que la virtualisation, les conteneurs ou les comptes d’utilisateur, pour exécuter des processus avec l’ensemble minimal de privilèges.
Transparence de la sécurité
Tout comme la sécurité d’accès du code, la transparence de la sécurité sépare le code sandbox du code critique de sécurité d’une manière déclarative, mais n’est plus prise en charge en tant que limite de sécurité. Cette fonctionnalité est fortement utilisée par Silverlight.
Pour exécuter des processus avec le moins de privilèges, utilisez les limites de sécurité fournies par le système d’exploitation, telles que la virtualisation, les conteneurs ou les comptes d’utilisateur.
System.EnterpriseServices
System.EnterpriseServices (COM+) n’est pas pris en charge par .NET 6+.
Workflow Foundation
Windows Workflow Foundation (WF) n’est pas pris en charge dans .NET 6+. Pour obtenir une alternative, consultez CoreWF.
Conseil
Le serveur Windows Communication Foundation (WCF) peut être utilisé dans .NET 6+ à l’aide des packages NuGet CoreWCF. Pour plus d’informations, consultez CoreWCF 1.0 a été publié.
Certaines API d’émission de réflexion ne sont pas prises en charge
.NET 8 et versions antérieures de .NET (Core) ne prennent pas en charge l’enregistrement d’assemblys générés par les API System.Reflection.Emit, et la méthode AssemblyBuilder.Save n’est pas disponible. En outre, les champs suivants de l’énumération AssemblyBuilderAccess ne sont pas disponibles :
Dans .NET 9, une PersistedAssemblyBuilder a été implémentée et la méthode AssemblyBuilder.Save a été rajoutée à la bibliothèque d’émission de réflexion. Pour en savoir plus sur l’utilisation de cette API, consultez classe System.Reflection.Emit.PersistedAssemblyBuilder.
Pour plus d’informations sur les différentes implémentations AssemblyBuilder dans .NET, consultez classe System.Reflection.Emit.AssemblyBuilder.
Chargement d’assemblys multimodules
Les assemblys qui se composent de plusieurs modules (OutputType=Module dans MSBuild) ne sont pas pris en charge dans .NET 6+.
En guise d’alternative, envisagez de fusionner les modules individuels dans un seul fichier d’assembly.
Blocs de script XSLT
Les blocs de script XSLT sont pris en charge uniquement dans .NET Framework. Ils ne sont pas pris en charge sur .NET 6 ou version ultérieure.
