IDataContractSurrogate about standard HOT 15 CLOSED

@weshaggard just to avoid any confusion, I think you meant option (1)?

from standard.

As part of making NS2.0 compatible with NS1.6 we did end up adding ISerializationSurrogateProvider 5b11699

from standard.

Without fully understanding the pros and cons of each option it's a bit hard to tell which one is better. IDataContractSurrogate does not seem having high usage. Its usage is zero in top ~1000 Xamarin apps. So if just based on usage data, option 1 sounds reasonable. However, without IDataContractSurrogate, we will not be able to keep the entirety of some other serialization types such as DataContractSerializer in net standard 2. How important to keep the entirety of types in net standard?

cc: @shmao @mconnew

from standard.

I would like to go with option (1) but I worry a little about the fact we already had folks request this and we even created a new type ISerializationSurrogateProvider to satisfy the scenarios. Perhaps that will still be enough for folks if they need to support the scenario.

from standard.

Yes, for people who are using IDataContractSurrogate on .NET Framework today and want to move to NetStandard 2.0 without changing code, it's going to be an adoption blocker if we don't include IDataContractSurrogate. Honestly, I don't have any concrete usage data of IDataContractSurrogate on .NET Framework so it's hard to tell how many potential customers this may impact. ISerializationSurrogateProvider captured the most useful part of IDataContractSurrogate (it should have been two seperate interfaces in the first place) and was made as partial facade on .NET Core, so it will be a good alternative for people who only need to support .NET Core and .NET Framework and are willing to change code.

from standard.

Given the usage is low, it seems we should leave it out for now. We cannot add the new interface (ISerializationSurrogateProvider) because it doesn't exist in .NET FX 4.6.1 yet. However, the next version of the standard that can pre-req .NET Framework 4.6.3 (or later), we should add the new one to the standard, which means we need to add to it to the Xamarin platforms, too.

from standard.

@terrajobst does it mean we will need to add ISerializationSurrogateProvider to .NET Framework 4.6.3 even though the implementation of ISerializationSurrogateProvider on .NET Core is already made as partial façade?

from standard.

Yes we will need to add ISerializationSurrogateProvider to the .NET Framework if we ever want to support it and the scenario it enables in a future .NET Standard version.

We have landed on a decision got go with option (1) so closing this issue.

from standard.

Thanks @zhenlan I did mean option (1). I edited my earlier comment to avoid future confusion.

from standard.

Just wanted to comment on this. I use IDataContractSurrogate because my library can use different graphical rendering libraries (OpenGL based or DirectX or something else) and while they have the same concepts (A Color type is 4 bytes) they may change the order of these things. If someone serializes a type from my library which references one of these types (like Color) someone who loads that file using a different rendering library will get an exception because it cannot deserialize that type properly.

I used IDataContractSurrogate to fix this problem by doing automatic mapping. I have my own Color type purely for serialization. These are used behind the scenes automatically so as to not burden the user of my library.

For .NET Standard, I don't really care what provides this, I just want the ability for the serialization system to let me provide logic to map one type to another.

from standard.

For .NET Standard, I don't really care what provides this, I just want the ability for the serialization system to let me provide logic to map one type to another.

That's fair. Our challenge is that we can only expose APIs that already exist in the .NET platforms, otherwise, the standard wouldn't be useful :-) Unfortuantely, the existing APIs don't work because there are incompatible API shapes. I think that feature will have to wait until we can rev the standard again.

from standard.

Man.. I already ripped all the code out and did translations by hand 😆

from standard.

Man.. I already ripped all the code out and did translations by hand

Sorry about that. The hand translations might still be necessary in some cases as this code will still not run on .NET Framework 4.6.1 yet so most libraries that have a hard dependency on it will either have to do it manually or #ifdef for .NET Framework.

from standard.

No worries, I think it's better this way anyway. Since the surrogate needed a translation mapping, some of my other libraries needed to then register themselves with the main library since all the code went through a single helper class for serialization. So this issue is avoided.

Thanks though 👍

from standard.

I'm currently porting code from .Net Framework to .Net Standard and I have the problem that our code is massively using IDataContractSurrogate. @Thraka was asking for a mapping of one type to another.

I don't see any implementations of such a mapping in .Net Standard 2.0. How does this mapping work?

from standard.