We are creating a package to deserialize certain XML-files using code generated by xsd.exe. Some "though"s:
- We are using Xamarin (iOS and Android) using Visual Studio for Mac 2017.
- We are using an MvvmCross-setup with a core (PCL), platform and shared code projects, though MvvmCross is not involved in this problem.
- The code generated by xsd.exe lies in the shared code project.
- As we want to be able to use the deserialized objects in the core/PCL, we extracted interfaces from the types generated by xsd.exe and let the generated types implement those interfaces.
- To make that work, all properties, the deserializer uses, were annotated with
[XmlElement(Type = <concrete-type>)], as the properties themselves are now interfaces.
When using this construct on the platforms, this works just fine.
Though, when using this in the NUnit-project, we get an exception:
System.NotSupportedException : Cannot serialize member <concrete-type> of type <interface-type> because it is an interface.
As if the [XmlElement]-attribute wasn't there.
We were unable to find the reason so far and hope to find wisdom here :-) So does anybody know, why that happens and/or how we can resolve it?
Btw.: If there is any easier or better practice way of using XML deserialization with PCL-code, let me know.
Additional information
- Code files in shared code projects are "copied" to projects referencing the shared code project prior to compilation. Hence the referencing project compiles the shared code, as if it was its own code.
- The NUnit project compiles as a library, which is effectively platform-code and has all of .NET available. By referencing the shared code project, which contains the concrete types, those are compiled as if they were part of the test-project.
- Differences in referenced System.Xml-versions detected:
- iOS-project: System.Xml v2.0.5.0 of Xamarin.iOS
- Android-project: System.Xml v2.0.5.0 of Xamarin.Android
- NUnit-project: System.Xml v4.0.0.0 of .NET Framework v4.6.1