Runtime: System.Text.Json with interface : serialization is empty.

[Francescolis]

NET 5.0
Something very strange : I migrated a library from Newtonsoft to System.Text.Json and I encountered a surprise.

``` C#
public record Name(string Value) : ICommand; // ICommand is just used as a marker.

ICommand name = new Name("myname");
var systemTextJson = System.Text.Json.JsonSerializer.Serialize(name);
var newtonsoftJson = Newtonsoft.Json.JsonConvert.SerializeObject(name);

Console.ReadLine();
// systemTextJson result is {} ???????
// newtonsoftJson result is {"Value":"myname"}

```

What am I doing wrong ?

[huoyaoyuan]

The covariance of serialization only applies when the property is declared as object. Otherwise, it will use the declared type, not actual object type.

[Francescolis]

@huoyaoyuan

Thank you for your response.

But this operation is native in Newtonsoft and I would have to modify all my code to use this library and I think I'm not the only one. When something is simple, keep it simple.

Name attributes are not valid for parameters.

I use this code for IAsyncEnumerable with Stream.

``` C#
// Using Newtonsoft

public static async IAsyncEnumerable ReadAsyncEnumerableFromStreamAsync(
this Stream stream, [EnumeratorCancellation] CancellationToken cancellationToken = default)
{
var jsonSerializer = JsonSerializer.CreateDefault();
using var streamReader = new StreamReader(stream);
using var jsonTextReader = new JsonTextReader(streamReader);
while (await jsonTextReader.ReadAsync(cancellationToken).ConfigureAwait(false))
{
if (jsonTextReader.TokenType == JsonToken.StartObject)
if (jsonSerializer.Deserialize(jsonTextReader) is TResult result)
yield return result;
}
}

```

I haven't figured out how to do it with System.Text.Json. Do you have an idea?

And when I look further, System.Text.Json is not ready for production because it requires a lot of changes (changing Interfaces for objects leads to a loss of inheritance, write your own converters, your own attributes, use options ...).

NET 5.0 and C# 9.0 should allow to write less code and focus on the essentials, but with System.Text.Json, you will have to write even more code.

Guys, this library is not at all easy to use.

[huoyaoyuan]

Name attributes are not valid for parameters.

record SystemTextJsonRecord([property: JsonPropertyName("id")] int Id);

[huoyaoyuan]

Guys, this library is not at all easy to use.

I did face problems when migrating too. This library is designed for maximum performance. It does consider Newtonsoft.Json in mind, but full feature parity is non-goal.

[Joe4evr]

And when I look further, System.Text.Json is not ready for production because it requires a lot of changes (changing Interfaces for objects leads to a loss of inheritance, write your own converters, your own attributes, use options ...).

Well, S.T.Json was never meant to be a 1:1 replacement for Json.Net; it was meant to be fast. That comes with trade-offs.

[oliverjanik]

Hang on a second. Let's not be dismissive just yet.

I have a full tree of objects which declare their nested properties as interfaces. Using object at top level might work but how do you propose I use object for nested properties?

This seems like an oversight in functionality. And, please don't hand-wave it under "it's about performance".

What's the performance impact of using specific type behind interface? Do you have some numbers? Let me opt into this behaviour I'd happily accept small performance downgrade for correct behaviour.

[Francescolis]

Guys, this library is not at all easy to use.

I did face problems when migrating too. This library is designed for maximum performance. It does consider Newtonsoft.Json in mind, but full feature parity is non-goal.

@huoyaoyuan
I'm not looking for full feature parity, just basic functionality.

[Francescolis]

And when I look further, System.Text.Json is not ready for production because it requires a lot of changes (changing Interfaces for objects leads to a loss of inheritance, write your own converters, your own attributes, use options ...).

Well, S.T.Json was never meant to be a 1:1 replacement for Json.Net; it was meant to be _fast_. That comes with trade-offs.

@Joe4evr

Being fast has nothing to do with it. It's simply basic functionality. As @oliverjanik said, it seems more an oversight than anything else. What's the point of having something said faster if the first basic functionality is not possible or requires a complete rewrite of the code?

[layomia]

This is a duplicate of https://github.com/dotnet/runtime/issues/29937. We are looking at extending polymorphic support in .NET 6.0 (https://github.com/dotnet/runtime/issues/45189). This feature is one of the cases where users can opt-in to (potentially) slower code-paths to get impactful functionality.