Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Avertissement
Nous vous recommandons vivement d’utiliser BinaryFormatter en raison des risques de sécurité associés. Les utilisateurs existants doivent migrer loin de BinaryFormatter.
À compter de BinaryFormatter .NET 9, nous n’incluons plus d’implémentation dans le runtime. Les API sont toujours présentes, mais leur implémentation lève toujours un PlatformNotSupportedException, quel que soit le type de projet. Par conséquent, la définition de l’indicateur de compatibilité descendante existante n’est plus suffisante pour l’utilisation BinaryFormatter.
Vous avez deux options pour résoudre ce qui suit :
Migrer loin de BinaryFormatter. Nous vous recommandons vivement d’examiner les options permettant de cesser d’utiliser BinaryFormatter en raison des risques de sécurité associés. Nous listons plusieurs options ci-dessous.
Continuez à utiliser BinaryFormatter. Si vous devez continuer à utiliser BinaryFormatter dans .NET 9, vous devez dépendre du System.Runtime non pris en charge.Serialization Met en forme le package NuGet, qui remplace l’implémentation de levée.
Quel est le risque d’utilisation BinaryFormatter?
Tout désérialiseur, binaire ou texte, qui permet à son entrée de transporter des informations sur les objets à créer est un problème de sécurité en attente de se produire. Il existe une énumération de faiblesse courante (CWE) qui décrit le problème : CWE-502 « Désérialisation des données non approuvées ». BinaryFormatter, inclus dans la version initiale de .NET Framework en 2002, est un tel désérialiseur. Nous abordons également ce problème dans le guide de sécurité BinaryFormater.
En raison des risques connus liés à l’utilisation BinaryFormatter, la fonctionnalité a été exclue de .NET Core 1.0. Mais sans un chemin de migration clair pour utiliser quelque chose de plus sûr, la demande des clients a conduit à BinaryFormatter être inclus dans .NET Core 2.0. Depuis lors, l’équipe .NET a été sur le chemin de la suppression BinaryFormatter, la désactivant lentement par défaut dans plusieurs types de projets, mais permettant aux consommateurs d’opter via des indicateurs si nécessaire pour la compatibilité descendante.
Pour plus d’informations sur la décision, consultez l’annonce BinaryFormatter de .NET 9 .
Si vous rencontrez des problèmes liés à BinaryFormatterla suppression de ' non résolu dans ce guide de migration, veuillez signaler un problème à github.com/dotnet/runtime et indiquer que le problème est lié à la suppression de BinaryFormatter.
Rubriques relatives à la migration
La migration loin d’un BinaryFormatter autre sérialiseur signifie généralement choisir un autre sérialiseur. Toutefois, cela n’est généralement possible que si vous contrôlez à la fois le producteur et le consommateur des données encodées. Si vous ne contrôlez pas le producteur, vous pouvez également passer à notre nouvelle API pour lire BinaryFormatter des charges utiles sans instancier les types encodés.
Les deux options sont explorées ci-dessous.
Choisir un sérialiseur
La première étape de la migration BinaryFormatter consiste à choisir un sérialiseur à utiliser à sa place. Selon vos besoins spécifiques, l’équipe .NET recommande des migrations vers quatre sérialiseurs différents.
- Migrer vers System.Text.Json (JSON)
- Migrer vers DataContractSerializer (XML)
- Migrer vers MessagePack (binaire)
- Migrer vers protobuf-net (binaire)
Lire les charges utiles BinaryFormatter (NRBF)
De nombreuses applications chargent et désérialisent les charges utiles qui ont été conservées dans le stockage et il n’est pas toujours possible de transformer toutes les charges utiles persistantes en amont. D’autres scénarios peuvent impliquer des systèmes ou des services qui reçoivent des données produites par BinaryFormatter, où ces systèmes doivent être migrés indépendamment.
Dans ces scénarios et d’autres, il est nécessaire de conserver la prise en charge de la lecture des charges utiles fournies et de passer à un nouveau format au fil du temps. Pour répondre à ces besoins, il est désormais possible de lire en toute sécurité des charges utiles NRBF crééesBinaryFormatter sans effectuer de désérialisation à usage général et vulnérable.
Migrer des applications Windows Forms et WPF
Les applications Windows Forms et WPF peuvent nécessiter des modifications supplémentaires. Consultez les applications Windows Forms, les applications WPF et le Presse-papiers WinForms/WPF et les instructions de glisser-déplacer pour obtenir des conseils supplémentaires sur la migration.
Migrer des ressources managées (ResX)
Les types de ressources les plus courants (tels que les chaînes et les icônes) fonctionnent sans BinaryFormatter. Pour les types personnalisés, vous devez entrer BinaryFormatter et activer un commutateur de compatibilité, consultez La ressource de chargement pendant l’exécution.
Utiliser le package de compatibilité
Pour les scénarios où une migration ne BinaryFormatter peut pas être effectuée au moment de la mise à niveau vers .NET 9, un package de compatibilité non pris en charge est disponible. System.Runtime.Serialization. Le package NuGet de formateur contient l’implémentation fonctionnelle de BinaryFormatter, y compris ses vulnérabilités et ses risques.
Bien qu’il ne soit pas pris en charge et non recommandé, le guide d’utilisation du package de compatibilité inclut les détails de l’installation du package et l’activation des fonctionnalités.
Avertissement
Nous vous recommandons vivement d’utiliser BinaryFormatter en raison des risques de sécurité associés. Les utilisateurs existants doivent migrer loin de BinaryFormatter.