Question

NOTE: XMLIgnorer n'est PAS la réponse !

OK, donc suite à ma question sur Sérialisation XML et types hérités, j'ai commencé à intégrer ce code dans mon application sur laquelle je travaille, pensant bêtement que tout ira bien.

J'ai rencontré des problèmes avec quelques classes que j'ai mises en œuvre IEnumerable et ICollection<T>

Le problème avec ceux-ci est que lorsque XMLSerializer vient les sérialiser, il les considère comme une propriété externe, et au lieu d'utiliser la propriété que nous aimerions (c'est-à-direcelui avec notre AbstractXmlSerializer ) il vient ici et tombe (en raison de l'inadéquation des types), nous ramenant à la case départ.Vous ne pouvez pas décorer ces méthodes avec le XmlIgnorer attribut non plus, nous ne pouvons donc pas l'arrêter de cette façon.

Ma solution actuelle consiste à supprimer l’implémentation de l’interface (dans cette application actuelle, ce n’est pas vraiment grave, je viens de rendre le code plus joli).

Dois-je ravaler ma fierté et accepter que cela ne soit pas possible ? Je sais que j'ai un peu poussé et obtenu plus de XmlSerializer que ce à quoi on s'attendait :)


Modifier

Je dois également ajouter que je travaille actuellement dans le framework 2.


Mise à jour

j'ai accepté La réponse de Lomaxx.Dans mon scénario, je ne peux pas réellement faire cela, mais je sais que cela fonctionnera.Comme il n’y a eu aucune autre suggestion, j’ai fini par supprimer l’implémentation de l’interface du code.

Était-ce utile?

La solution

vous pouvez contourner ce problème en vous procurant la DLL System.RunTime.Serialization (il s'agit d'un assemblage .net 3.x) et en la référençant à partir de votre application .net 2.0.Cela fonctionne car les binaires .net 3.0 sont compilés pour s'exécuter sur le CLR .net 2.0.

En faisant cela, vous avez accès au DataContractSerliazer que j'ai utilisé pour contourner un problème similaire où je voulais transmettre une ICollection en tant que paramètre à un service Web et le xmlserializer ne savait pas comment le gérer correctement.

Si vous êtes d'accord avec l'utilisation de la DLL .net 3.x dans votre application 2.x, vous devriez pouvoir utiliser DataContractSerializer pour résoudre ce problème.

Autres conseils

je suppose que la réponse arrive trop tard pour être utile pour votre application particulière, mais peut-être que d'autres personnes ont le même problème.

je suppose que vous pouvez implémenter IXmlSerializing pour le type IEnumerable afin de contourner ce comportement.cependant, cela signifie que vous devez contrôler entièrement le processus de sérialisation pour ce type.une approche simple pour ne pas avoir à jouer avec XmlReader / XmlWriter, vous pouvez écrire une classe d'adaptateur XML d'assistance avec un ctor public et des propriétés publiques de lecture-écriture de toutes les données à sérialiser, et créer un objet XmlSerializer temporaire pour ce type à l'intérieur IXmlSerialisisable.[Lecture|Ecriture]Xml().

class Target : IEnumerable<Anything>, IXmlSerializable
{
//...

public void ReadXml(System.Xml.XmlReader reader)
{
    reader.ReadStartElement();
    TargetXmlAdapter toRead = (TargetXmlAdapter)new XmlSerializer(typeof(TargetXmlAdapter)).Deserialize(reader);
    reader.Read();

    // here: install state from TargetXmlAdapter
}

public void WriteXml(System.Xml.XmlWriter writer)
{
    // NOTE: TargetXmlAdapter(Target) is supposed to store this' state being subject to serialization
    new XmlSerializer(typeof(TargetXmlAdapter)).Serialize(writer, new TargetXmlAdapter(this));
}
}

Si vous utilisez ces attributs :

        [XmlArray("ProviderPatientLists")]
        [XmlArrayItem("File")]
      public ProviderPatientList Files
    {
        get { return _ProviderPatientLists; }
        set
        {
            _ProviderPatientLists = value;
        }
    }

Où ProviderPatientList hérite de List<PatientList>

Vous pouvez alors avoir plus de contrôle sur le XML sorti

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top