no se puede - así de simple. El atributo es necesario para que DataContractSerializer recoja los elementos a serializar. En contrato con el XmlSerializer, que básicamente solo serializa todo (a menos que explícitamente le diga que lo ignore), DataContractSerializer es "opt-in" - debe decirle explícitamente (por medio de los atributos) qué campos y/o propiedades serializar
ACTUALIZACIÓN: Como varias personas han señalado, con .NET 3.5 SP1, Microsoft afloja esas reglas un poco - cualquier público de lectura/escritura de propiedad será serializado automáticamente por DataContractSerializer. Al mismo tiempo, su clase y también debe tener un constructor sin parámetros por defecto - suena como los requisitos exactos que teníamos para XmlSerializer camino de regreso cuando ....
Por supuesto, esto:
- no lo hace le permite serializar algo privado; si desea serializarlo, debe exponerlo como propiedad de lectura/escritura pública
- no le permite especificar un orden definido definido de los parámetros; simplemente los usará en el Para que aparezcan en la clase
- ahora requiere que tenga un constructor sin parámetros en su clase de nuevo para deserialización
r sigo pensando estas cosas debe ser explícita y clara, por lo que los que ya no se requiere abre el camino para la programación perezoso/descuidado - No me gusta. Pero si se quiere, se puede usar ahora sin marcar explícitamente sus propiedades con [DataMember] .....
Marc
Realmente esperaba que estuvieras equivocado, pero después de mucho googleo me temo que tienes razón. No se puede usar XmlSerializer (problema de referencia circular que funciona con Entity Framework). Ah, bueno, las clases anónimas sí lo son. – aleemb
Bueno, he leído un poco más sobre esto hoy, y aquí encontré que si sus clases utilizadas por el DataContractSerializer están marcadas con [Serializable], entonces de manera predeterminada serán serializadas al igual que el formateador SOAP de estilo antiguo - CADA un solo campo independientemente de la visibilidad está incluido. ¿Podría ser de ayuda para usted tal vez? –
Bueno, no realmente porque mi problema es que no puedo tocar las clases autogeneradas y necesito poder ignorar los campos externamente. Estoy usando proyecciones en mis consultas de linq para solucionar esto ahora que funciona bien. – aleemb