Compartir a través de


Instrucciones de serialización

Debe considerar la posibilidad de serializar al diseñar nuevas clases porque una clase no se puede serializar después de haberla compilado. Éstas son algunas de las preguntas que debe plantearse: ¿Será necesario enviar esta clase por dominios de aplicación? ¿Se utilizará esta clase con interacción remota? ¿Qué van a hacer los usuarios con esta clase; es posible que vayan a derivar una nueva clase que se deba serializar? Cuando tenga dudas, marque la clase como serializable. Probablemente es mejor marcar todas las clases como serializables a menos que alguna de estas afirmaciones sea verdadera:

  • La clase nunca va a pasar de un dominio de aplicación a otro. Si la serialización no es necesaria y la clase debe cruzar un dominio de aplicación, derive la clase de MarshalByRefObject.

  • La clase almacena punteros especiales que sólo son aplicables a la instancia actual de la clase. Si, por ejemplo, una clase contiene memoria no administrada o identificadores de archivos, asegúrese de marcar estos archivos con el atributo NonSerializedAttribute, o no serialice la clase.

  • Los miembros de datos de la clase contienen información confidencial. En este caso, es recomendable marcar la clase como serializable, pero marcar los miembros de datos individuales que contienen información confidencial con el atributo NonSerializedAttribute. Otra alternativa es implementar la interfaz ISerializable y serializar solamente los campos necesarios.

Tenga en cuenta las implicaciones de seguridad derivadas de marcar una clase como serializable. Se puede omitir de manera predeterminada una Link Demand o una Inheritance Demand para un permiso CodeAccessPermission en una clase o en un constructor de clases, o la serialización personalizada que implementa una solicitud correspondiente para el mismo permiso CodeAccessPermission. Para obtener más información, vea la enumeración SecurityAction. Si una clase tiene una Link Demand para un permiso, el motor de tiempo de ejecución comprueba únicamente el llamador inmediato para comprobar que se le haya concedido el permiso. El código de la biblioteca de clases de .NET Framework está firmado con el nombre seguro de Microsoft y siempre se le concede una confianza total. Cualquier código puede utilizar código que posea una confianza total para pasar por alto comprobaciones de seguridad en tiempo de enlace. Por ejemplo, en el caso de la serialización, el código malicioso que no posee el permiso de serialización requerido puede llamar a uno de los formateadores de plena confianza de .NET Framework, como BinaryFormatter y omitir la comprobación de solicitud de vínculo para el permiso.

Vea también

Conceptos

Security and Serialization

Otros recursos

Serialización binaria
Objetos remotos
Serialización XML y SOAP