Indications de sérialisation

Vous devez prendre la sérialisation en compte lorsque vous concevez de nouvelles classes, parce qu'une classe ne peut plus devenir sérialisable une fois compilée. Posez-vous les questions suivantes : cette classe devra-t-elle être envoyée à différents domaines d'application ? Cette classe sera-t-elle utilisée avec l'accès distant ? Que feront les utilisateurs avec cette classe ? Pourront-ils dériver de cette classe une nouvelle classe qui devra être sérialisée ? En cas de doute, marquez la classe comme étant sérialisable. Mieux vaut probablement marquer toutes les classes comme étant sérialisables à moins que n'importe laquelle des propositions suivantes soit vraie :

• La classe ne franchira jamais de domaine d'application. Si la sérialisation n'est pas obligatoire et si la classe doit franchir un domaine d'application, dérivez la classe de MarshalByRefObject.
• La classe stocke des pointeurs spéciaux qui ne sont applicables qu'à l'instance actuelle de la classe. Si une classe contient de la mémoire non managée ou des handles de fichiers, par exemple, vérifiez que ces fichiers sont marqués comme étant NonSerialized ; vous pouvez aussi ne pas sérialiser la classe.
• Les données membres des classes contiennent des informations sensibles. Dans ce cas, il est judicieux de marquer la classe comme étant sérialisable, mais de marquer les données membres individuelles contenant des informations sensibles comme NonSerialized. Une autre solution consiste à implémenter l'interface ISerializable et à ne sérialiser que les champs requis.

Tenez compte des implications en terme de sécurité du marquage d'une classe comme étant sérialisable. Une demande de liaison ou une demande d'héritage pour une autorisation CodeAccessPermission sur une classe ou un constructeur de classe peut être ignorée par défaut ou par une sérialisation personnalisée qui implémente une demande correspondante pour la même autorisation CodeAccessPermission. Si une classe a une demande de liaison pour une autorisation, le runtime ne contrôle que l'appelant immédiat pour s'assurer qu'il dispose de l'autorisation. Le code de la bibliothèque de classes du .NET Framework est signé avec le nom fort Microsoft et dispose toujours de l'autorisation de confiance totale. N'importe quel code peut utiliser du code disposant d'une autorisation de confiance totale pour passer outre les contrôles de sécurité au moment de la liaison. Par exemple, dans le cas de la sérialisation, du code nuisible ne possédant pas l'autorisation de sérialisation requise peut appeler l'un des formateurs .NET Framework bénéficiant d'une confiance totale, tels que BinaryFormatter, et outrepasser ainsi le contrôle de demande de liaison pour l'autorisation.

Voir aussi

Sérialisation binaire | Accès aux objets dans d'autres domaines d'application à l'aide de .NET Remoting | Sérialisation XML et SOAP | Sécurité et sérialisation