System.Text.Json
This is a sincerely meant question, not a bug report.
Why is de-serialization of immutable classes so poorly supported?
(or one might argue that "not at all" is more precise than "poorly" unless custom converters are deemed support for such case).
By support I mean mostly ability to use parameterized (maybe not public) constructors and private setters during deserialization.
a) Is it by design for performance reasons?
b) Is it just a result of not enough time and it will be supported sometime in near future?
If a) is the answer what are the implications for the rest of the code?
1) throw immutability out of the window?
2) have dedicated layer of classes just for de/serialization which are immediately translated to immutable DTOs used down the line. (I wonder what would that do for overall performance even if the serialization framework would do better on its own).
Tagging subscribers to this area: @eiriktsarpalis
Notify danmosemsft if you want to be subscribed.
Tagging subscribers to this area: @jozkee
Notify danmosemsft if you want to be subscribed.
We have addressed these issues for .NET 5:
You can try these features in preview 4 of .NET 5 or the System.Text.Json package on Nuget.
These have always been on the roadmap for System.Text.Json, but were scoped out of 3.x due to time constraints and feature scoping. Please see the System.Text.Json project board for 5.0 for an overview of what we are prioritizing in this release.
Most helpful comment
We have addressed these issues for .NET 5:
You can try these features in preview 4 of .NET 5 or the System.Text.Json package on Nuget.
These have always been on the roadmap for System.Text.Json, but were scoped out of 3.x due to time constraints and feature scoping. Please see the System.Text.Json project board for 5.0 for an overview of what we are prioritizing in this release.