Technologies .NET Framework non disponibles sur .NET

  • Article

Plusieurs des technologies disponibles dans les bibliothèques .NET Framework ne sont pas utilisables avec .NET 6+, notamment les domaines d’application, le remoting et la sécurité d’accès du code (CAS). Si vos bibliothèques s’appuient sur une ou plusieurs des technologies répertoriées sur cette page, vous pouvez utiliser les 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’est pas prévu que cette fonctionnalité soit ajoutée à 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 de code à partir de .NET Framework, .NET 6+ expose une partie de la surface d’API AppDomain. Certaines API fonctionnent normalement (par exemple, AppDomain.UnhandledException), certains membres ne font rien (par exemple, SetCachePath) et d’autres lèvent PlatformNotSupportedException (par exemple, CreateDomain). Vérifiez les types que vous utilisez sur 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

.NET Remoting n’est pas pris en charge sur .NET 6+. Le remoting .NET a été identifié comme architecture problématique. Il est utilisé pour communiquer dans l’ensemble des domaines d’application, lesquels 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.

Pour la communication entre ordinateurs, utilisez plutôt une solution réseau. Choisissez de préférence un protocole de texte brut à faible charge, par exemple HTTP. Le serveur web Kestrel qui est utilisé par ASP.NET Core est une possibilité. Vous pouvez également envisager d’utiliser System.Net.Sockets pour les scénarios réseau sur différents ordinateurs. 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 la page Projets de développement .NET open source : messagerie.

Étant donné que la communication à distance n’est pas prise en charge, les appels vers BeginInvoke() et EndInvoke() sur des objets délégués lèvent PlatformNotSupportedException. Pour plus d’informations, consultez Migration des appels BeginInvoke délégués pour .NET Core.

Sécurité d’accès du code (CAS)

Le sandboxing, qui s’appuie sur le runtime ou le framework pour limiter les ressources utilisées ou exécutées par une bibliothèque ou une application managée, n’est pas pris en charge sur .NET Framework ni, par conséquent, sur .NET 6+. La sécurité d’accès du code n’est plus considérée comme une limite de sécurité car les cas sont trop nombreux dans .NET Framework et le runtime où une élévation des privilèges se produit. En outre, la sécurité d’accès du code complique l’implémentation et a souvent des implications en matière de performances d’exactitude pour les applications qui ne prévoient pas de l’utiliser.

Servez-vous des limites de sécurité fournies par le système d’exploitation, comme la virtualisation, les conteneurs ou les comptes d’utilisateurs, pour exécuter des processus avec l’ensemble de privilèges minimal.

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 très utilisée par Silverlight.

Pour exécuter des processus avec l’ensemble de privilèges le plus petit possible, utilisez les limites de sécurité fournies par le système d’exploitation, comme la virtualisation, les conteneurs ou les comptes d’utilisateurs.

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+ par le biais 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, un PersistedAssemblyBuilder a été implémenté et la méthode AssemblyBuilder.Save a été ajoutée à la bibliothèque d’émission de réflexion. Pour en savoir plus sur l’utilisation de cette API, consultez la classe System.Reflection.Emit.AssemblyBuilder.

Pour plus d’informations, consultez Problème dotnet/runtime 15704.

Chargement d’assemblys multimodules

Les assemblys constitués 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 les versions ultérieures.

Voir aussi