-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Developers using JsonSerializer have support for polymorphic types #45189
Comments
System.Text.Json is not going to be usable until it can handle serialization of objects. Even then, if including all of the properties is not made the default behavior I'm still going to have to avoid using it. Why would an entire product team think that any data loss would be acceptable? Especially by default. |
Extending polymorphic support has always been on the roadmap for System.Text.Json. We do not consider this feature an edge case. We just couldn't get to it in previous releases due to product scoping and time constraints. As this issue indicates, it is being planned for .NET 6.0. Polymorphic (de)serialization cannot be made the default behavior because that would be a breaking change from previous versions of System.Text.Json. Polymorphic serialization can also lead to accidental information disclosure when a object is treated as a different type than declared to the serializer. Such behavior needs to be opt-in only. Not having built-in support for polymorphic is not a ship-blocker as many applications do not need this feature. Following up on #45764: System.Text.Json was not designed to be a drop-in replacement for Newtonsoft.Json. You are free to continue using it if it satisfies your use cases. Please see our migration guide for some clarity about the relationship between the two libraries:
|
@layomia - A Breaking Change means just incrementing the Major Version number I thought. You can say that this is not intended to be a drop in replacement for newtonsoft's package, but being able to serialize an object completely is one of those things that is expected to work in a package like this. What good is the performance going to be to me if its not able to do the primary job? Is getting it to do the complete job going to net worse performance than the existing package? If you asked 100 random .net developers (that are not already familiar with this shortfall of S.T.J) what Polymorphic Serialization is, you would get maybe one that could correctly answer what it meant, but I would bet $1 that this affects more than 75% of them. The doc page should say "Can serialize base class members? Not supported" |
Please, please keep deserializing the shape of the declared type by default. This unintended information disclosure was the thing I hated about Json.Net the most. It is imperative that if your array of type User, it doesn't show President instead. It has to be opt-in. Thank you for making it for us. |
Anyone concerned about information disclosure should be using DTOs for the exposed API that don't have the unwanted properties on them. Asking to have a tool crippled for everyone else because some people are unwilling to model their API data is a request that should not be taken seriously. |
this is only valid when the declared property type is object. If you deserialize to an interface or base type you know exactly what to expect. include type information only when the runtime type isn’t the same as the declared type and you will be safe. |
@qsdfplkj Is this a typo or an actual thing? |
Isn’t it just that JavaScript is not really polymorphic but a dynamic language. |
Closing this, since it is specifically tracking polymorphism-related work for .NET 6. Individual pending work items have been reassigned to different milestones. |
@eiriktsarpalis - are those other work items something that non-msft users can see? |
All planning and issue tracking happens publicly on github: I was referring to the open issues that are linked in the original post. |
Work
The text was updated successfully, but these errors were encountered: