Classes imbriquées avec le même nom dans des assemblages distincts provoquant des céphalées de sérialisation

Question

Je travaille avec une API mal conçue. J'ai une classe dont j'ai besoin pour sérialiser, et j'ai le contrôle sur la composition de la classe, mais pas sur les types qui composent les propriétés que la classe sérielle. Un exemple est ci-dessous:

<Project> 
    <SomeProperty1 /> 
    <Install> 
    <DefaultStep></DefaultStep> 
    </Install> 
    <Uninstall> 
    <DefaultStep></DefaultStep> 
    </Uninstall> 
</Project> 

Le problème est, je ne contrôle pas les « Installer » et types « Désinstaller », et leurs types imbriqués ont le même nom. "Install" réside dans MyCompany.Install.dll et "Uninstall" réside dans MyCompany.Uninstall.dll. Mais le kicker est, MyCompany.Uninstall.dll refererences MyCompany.Install.dll, ce qui est complètement inutile. Je sais que c'est une mauvaise conception (tout le cadre que j'ai à traiter est terrible) mais je n'ai pas le choix de travailler avec.

L'erreur que je reçois est:

« Types 'MyCompany.Install.Uninstall.DefaultStep' et 'MyCompany.Install.DefaultStep' utilisent tous deux le nom du type XML, 'DefaultStep', à partir de l'espace de noms ''. Utilisez les attributs XML pour spécifier un nom XML unique et/ou un espace de noms pour le type. "

Ce serait une bonne idée, sauf que je n'ai aucun contrôle sur les assemblys qui contiennent les classes "Install" et "Uninstall".

Des idées?

Answer 1

J'ai trouvé une réponse qui fonctionne. Commentaires dans cet article: http://www.codeproject.com/KB/XML/xmlserializerforunknown.aspx

m'a conduit à cet article: http://mfharoon.blogspot.com/2006/12/using-ixmlserializable-to-overcome-not.html

La seule chose que vous devez changer est la ligne 108, qui doit lire:

writer.WriteAttributeString ("type", _parameters.GetType(). AssemblyQualifiedName.ToString());

Cela permettra à la sérialisation de fonctionner si le type est dans un assembly séparé.

HTH!

Answer 2

Si vous avez accès à .NET 3.5, j'utiliserais le sérialiseur DataContract et implémenterais un IDataContractSurrogate. La sérialisation de substitution vous permet de remplacer un type difficile qui falsifie la sérialisation avec un type alternatif au moment de la sérialisation. Vous avez un contrôle total sur la mère porteuse. Cela devrait vous aider à résoudre le problème.

http://msdn.microsoft.com/en-us/library/system.runtime.serialization.idatacontractsurrogate.aspx