Access to System.Runtime.Remoting.Metadata.W3cXsd2001 under .NET Standard

[tlwest]

System.Runtime.Remoting is not implemented in .NET Standard for various good reasons.

However, there are some utility classes that (as far as I can tell) don't depend on the main problematic parts of System.Runtime.Remoting. The one that concerns me is System.Runtime.Remoting.Metadata.W3cXsd2001 which includes classes for binary/hex conversion. Could this be added into .NET Standard under a different namespace?

It would save Framework -> Standard conversion effort for little cost to the .NET Standard framework.

[karelz]

The types there seem to be SOAP related. I wonder if they would fit better WCF or external library. It does not feel like something we should include in "core" BCL IMO.

[danmoseley]

@tlwest do you have code that uses only these types from Remoting (ie there is value in porting these alone)? Or is it more that you would like to write code that uses such types (ie., alternative types are OK)

@zhenlan are there equivalents of these types? Note in .NET Framework sources they are in clr\src\BCL\System\Runtime\Remoting\SoapInteropTypes.cs. These types are not entirely decoupled from remoting in .NET Framework, eg., they can throw RemotingException.

[tlwest]

Our code makes a fair bit of use of the SoapHexBinary class as a simple utility class (i.e. not connected with remoting). I can write a replacement, but if the only reason it's not included in .NET Standard is that it happens to be in the System.Runtime.Remoting namespace, then it's inclusion in .NET Standard would make porting of some projects just that much easier for others (albeit presumably requiring a namespace change).
If there's a philosophical reason for its removal, then that would be a different matter.

[danmoseley]

@tlwest .NET Standard changes more slowly than .NET Core. Unless you're writing a .NET Standard library (ie, a single binary that must run on both .NET Core and .NET Framework) it may be enough for us to port it to .NET Core.

[zhenlan]

@zhenlan are there equivalents of these types? Note in .NET Framework sources they are in clr\src\BCL\System\Runtime\Remoting\SoapInteropTypes.cs. These types are not entirely decoupled from remoting in .NET Framework, eg., they can throw RemotingException.

Add @mconnew @Lxiamail to help.

[huanwu]

@tlwest To workaround it, you can create a dummy class derived from XmlSerializationWriter and call FromByteArrayHex from your own method.

[tlwest]

@huanwu. Thank you! I will examine this approach as the closest to the current code that we can achieve.

[mconnew]

@tlwest, I'm closing this issue as it looks like you have a solution. Feel free to reopen if that doesn't work for you.