Désérialisation dans le mauvais type?

Bonjour,

Je débute totalement en C# & .Net ; j'espère que ma question ne va pas être trop idiote.
J'ai une classe, appelons-la A, qui possède un attribut de type B, qui hérite lui-même de NameObjectCollectionBase. Cette deuxième classe va donc, dans mon cas, stocker des paires clé / liste d'objets, pour me faciliter l'accès à ces listes.
Ensuite, j'ai un webservice qui va transmettre à un composant une instance de A. Lorsque je souhaite accéder à A.B depuis ce composant, B n'hérite plus de NameObjectCollectionBase mais est représenté sous la forme d'un tableau deux dimensions (une dimension pour les listes, l'autre pour le NameObjectCollectionBase) ; je perds donc l'avantage des clés, et cela devient assez catastrophique... Je vois cela depuis le fichier reference.cs (je crois) du service, généré automatiquement apparemment, et qui contient une version raccourci de mes classes, utilisable pour le remoting (si j'ai bien compris).
J'étais parti sur un problème de sérialisation. J'ai rajouté les fonctions Serialize() et Deserialize() (mais sans réelle instruction, juste pour voir si on passait dedans), mais cela ne change rien. J'avais tenté aussi en passant par une sérialisation non XML, en vain (et en plus on passe par du XML, à ce que j'ai vu dans le projet).
Donc si quelqu'un a une idée... j'ai un moyen de contourner ce problème (j'ai toujours les mêmes informations dans B, les indices sont fixes, donc je m'y retrouve, mais c'est moche...), mais j'aimerai bien comprendre d'où vient le problème.
Merci d'avance ! ;)

Bonjour,

Le custom tool chargé de générer le fichier reference.cs à partir du fichier WSDL de ton web service génère les listes comme NameObjectCollectionBase en fonction de propriétés que tu peux configurer.

Clique droit sur la référence de ton web service, dans les options qui apparaissent, tu peux sélectionner comment ton custom tool génère les listes. Dans ton cas, Array doit être sélectionné et c'est pour cela que ta collection est transformée en tableau dans reference.cs.

Merci beaucoup pour ton aide ! C'est génial si c'est aussi simple que ça !
Par contre, je ne trouve pas où modifier cette option. J'ai 4 projets dans ma solution, mon composant, ma page, le webservice et mes classes A et B (qui vont se retrouver dans une dll).
J'ai donc essayé de trouver ce dont tu parles au niveau de ma classe B, en vain, puis au niveau de la seule référence que j'ai vers le webservice (au niveau de mon composant, bien indiqué dans l'explorateur de solutions), je ne peux à nouveau rien faire à ce niveau. Puis j'ai regardé le webservice (puisque c'est lui qui contient les fichiers wsdl et reference.cs), et là encore, j'ai rien trouvé.
Si tu pouvais m'aider, ce serait vraiment sympa... ça doit vraiment être tout bête, mais je suis sous visual studio depuis seulement 2 semaines, je débute :mrgreen: merci ;)

Pour ça, tu dois clicker bouton droit sur la référence du service dans le programme qui consomme ton service.
Dans les items du menu contextuel, tu dois avoir un lien "Configurer la référence de service".
Dans la fenêtre qui apparaît, tu as type de collection dictionnaire et type de collection.

Par contre, juste une précision. Je n'ai pas l'impression qu'une classe héritant de NameObjectCollectionBase soit bien reconnu par WCF et le processus de sérialisation. J'ai fait un test chez moi, et c'est pas top.
Par contre, si tu fais aussi hériter ta classe B de IDictionnary<,>, cela résoud le problême.

Exemple :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

[DataContract] public class CompositeType { Dictionnaire m_dico = new Dictionnaire();   [DataMember] public Dictionnaire Dico { get { return m_dico; } set { m_dico = value; } } }   [CollectionDataContract] public class Dictionnaire : NameObjectCollectionBase, IDictionary<string,object> { .... }

---

A ce que j'ai vu, cette option n'existe que sous VS2008 non? parce que j'ai 2005... :? Il y a moyen de contourner cela? Le fait de faire hériter ma classe de IDictionnary<,> pourrait tout résoudre? (je n'ai pas encore testé cela, je le ferai dans l'heure)
Merci !

Ah ok :)

Sinon tu peux utiliser directement l'outil WSDL.exe pour générer ta classe proxy. Tu peux y accéder facilement à partir d'une invite de commande Visual Studio.

Je pense que ce qui t'intéresse dans l'outil est l'arguments "parameters". Celui-ci prend un fichier xml commençant par la balise <wsdlParameters>. Il est spécifié dans la documentation officielle que tu peux définir le type utilisé pour les dictionnaires et listes. Par contre, je n'ai pas trouvé de documentation explicite sur ce fichier xml à fournir. La doc MSDN n'est pas forcément très complète.

Sinon, je pense que faire hériter ta classe de IDictionnary comme dans mon exemple devrait simplement résoudre ton problème.

Alors, j'ai donc tenté de faire hériter ma classe de IDictionnary, et bin non, ça ne marche toujours pas : maintenant j'ai un DataSet dans mon reference.cs au lieu d'un tableau, mais c'est toujours pas ce que je veux... :mrgreen:
J'ai aussi écris moi-même les fonctions utilisées pour la sérialisation, ça change rien non plus... Je vais tenter avec wsdl.exe si j'ai un peu de temps... en tout cas, c'est bien chiant ce soucis, dingue que des choses comme ça existe...

edit : tiens d'ailleurs, si j'ai un DataSet, c'est parce que je désérialise mal mes données ?

J'ai testé mes fonctions ReadXml / WriteXml, elles ont l'air de fonctionner, même si je n'ai pas testé ça en détail... j'ai pourtant toujours mon DataSet. D'ailleurs, depuis cette modification, ma classe B n'existe toujours pas, mais en plus, les objets que contenaient B n'existent plus non plus... (B était donc mon dictionnaire, d'objets C... et là les C n'existent plus). Alors qu'avant, j'avais un tableau 2D de C...
En fait, les fonctions de sérialisation sont dans la classe B, et elles se chargent de gérer aussi la sérialisation de la classe C... je lis chaque paire du dictionnaire, je rajoute la clé, puis je lis l'objet C (qui ne contient qu'un entier et un string). C n'étant donc plus sérialisé "d'office", le problème peut venir de là?