XsdDataContractExporter throws PNSE

[zvrba]

What are the plans for XsdDataContractExporter in netcore? Calling CanExport() or Export() throws PNSE with The implementation of the function requires System.Runtime.Serialization.IDataContractSurrogate which is not supported on this platform.

I've found an issue that decided to omit IDataContractSurrogate from netstandard2.0. Are there any ways around this, e.g., by setting some options?

[Lxiamail]

@zvrba This is a feature request. Can you share more context what scenario uses the APIs?

[zvrba]

The story begins with netcore not having a viable/supported/widely-used cross-platform UI framework for desktop. My application is therefore split into a back-end written in netcore / C# and a UI front-end written in Java. I want to exchange type-safe structured data (classes) between the back-end and the front-end and I want to do it in the most automatic way possible. After doing a lot of research, XML turned out to be the only [1] viable candidate for portable exchange structured data in a type-safe way.

So, the backend defines the business logic and data transfer classes using DataContract / DataMember [2]. Then I export the XML schema set and compile it with xjc into Java classes. (De)serializing XML from/to classes works like a charm on both sides. (I use reflection to collect relevant classes for export, i.e., I do not use svcutil.exe or xsd.exe.)

All DTC assemblies target netstandard2.0, so currently I have a small project targeting net472 that does the actual schema export. This is an acceptable workaround, but it raises serious questions about netcore's (as a platform) story about interop with other technologies. As I wrote, data exchange works fine, but the critical part -- schema export (maybe not even import?) -- is not supported by the platform!

NB! I'm not requesting IDataContractSurroagate feature: schema export is sufficient if it can be implemented without the "surrogate stuff".

Alternately, I'd be just as happy if XmlSerializer got modernized and integrated with System.Runtime.Serialization so that it supports the same features as other serializers, but what are the chances (and timeline!) of that happening?

[1] I had also investigated Microsoft Bond, but there are bug reports about it not working with newer Java SDKs. I also store the data into SQLServer as XML and query it there as XML, so I didn't have to implement Bond -> XML conversion. (Bond's implementation is incomplete.)

[2] Up until now I've used XmlSerializer, but it has too many limitations, e.g., it can't (de)serialize object graphs, and doing this manually has become quite cumbersome. (I serialize everything flat and cross-link objects with Guids.) It can't serialize private fields with public getters (w/o setter) either, which is also a nice feature to have for enforcing invariants. (E.g., the mentioned Guid should be immutable on each object instance.) It also doesn't support "quality of life" features like Nullable<>, DateTimeOffset, etc. Handling this manually is becoming tedious.