0

I have an old C# .net4 project that needed maintenance recently and one of the unit tests that was comparing a serialized object to a "staple" XML string started failing because of slight namespace differences, i.e. the namespace on the compare string was xmlns:xsd and on the serialized object it was xmlns:xsi. The weird thing is that the same unit test works fine on a different machine.

I'm rather clueless as to why this could happen.

Igor K.
  • 750
  • 9
  • 25
  • Is there any chance the two machines have a different setting for `useLegacySerializerGeneration` and/or `useLegacySerializationGeneration` (the docs are inconsistent about the name)? See https://learn.microsoft.com/en-us/dotnet/framework/wcf/feature-details/using-the-xmlserializer-class#xmlserializer-legacy-behavior and https://learn.microsoft.com/en-us/dotnet/standard/serialization/xmlserializer-element and [Serialization breaks in .NET 4.5](https://stackoverflow.com/q/14689305) – dbc Feb 16 '18 at 19:19
  • I'll check that, thanks for the tip! – Igor K. Feb 23 '18 at 09:20

2 Answers2

1

Change tests. You shold't compare xmls as strings. 

<a i="1" b="2"/>

is same as 

<a b="2" i="1"/>

if you compare it as strings they will be different, but as xml they are identical.

This post shoud help you.

BWA
  • 5,672
  • 7
  • 34
  • 45
  • I already did, but my question remains as to why would such a difference occur in the first place. – Igor K. Feb 16 '18 at 14:09
  • 1
    Same .NET, Windows and 32/64 bits on all machines? Maybe something like in [this post](https://social.msdn.microsoft.com/Forums/vstudio/en-US/cd01365d-f324-4682-a46d-eeb80575e31c/inconsistent-namespace-order-using-xmlserializer-on-x86x64?forum=csharpgeneral). – BWA Feb 16 '18 at 14:22
  • That's spot on what's happening, thanks! But it means that there is no magical solution :( oh well – Igor K. Feb 16 '18 at 15:39
  • 1
    @IgorK. - If all that differs is the attribute order, you can parse to an `XElement` and use [`XNode.DeepEquals(XNode, XNode)`](https://msdn.microsoft.com/en-us/library/system.xml.linq.xnode.deepequals(v=vs.110).aspx). I do that in tests all the time. – dbc Feb 16 '18 at 19:20
1

Don't know if it's your case, but, when I had to make some WCF retrocompatible with ASMX older webservices, it turned out that XmlSerializer works differently based on the version on the .NET framework, causing exceptions when trying to deserialize objects or re-read xml.

It makes sense that an older application, working on an old machine, with an old version of the framework might act differently on the new machine because even if the project targets an older framework, the newer one is used to elaborate some parts, such as the XML.

To add further details, I think the difference was between the passage from the 2.0 .NET framework to the newer ones (3, 3.5 etc). But I'm not sure of this, since quite some time has passed.

I repeat, I don't know if this is your case, but it might be a reason. One test should be to upgrade on the older machine the framework to the same version as the newer machine, and check if produces the same output, then do a system rollback to the previous state just before the installation of the newer framework.

Check this: this, absolutely THIS, and this.

Let me know if this was useful.

Liquid Core
  • 1
  • 6
  • 27
  • 52
  • My thoughts exactly. But I, in my naivety from being a relatively newcomer to the world of .NET, thought that framework 4 is the same regardless of anything and should behave the same way... – Igor K. Feb 16 '18 at 14:18
  • @IgorK. Well, you should try. I'm adding more details, check the question in a few minutes – Liquid Core Feb 16 '18 at 14:22
  • 1
    @IgorK. check the articles and let me know if it has been of any help – Liquid Core Feb 16 '18 at 14:25