System.Text.Json.Serialization.JsonSerializer should respect DataMemberAttribute.Name

[abelykh0]

The following code outputs {"MyDataMember":"dataMember"}, should be {"RENAMED":"dataMember"}

using System;
using System.Diagnostics;
using System.Runtime.Serialization;
using System.Text.Json.Serialization;

namespace JsonSerializerIssue
{
    [DataContract]
    internal class MyData
    {
        [DataMember(Name = "RENAMED")]
        public string MyDataMember { get; set; }
    }

    class Program
    {
        static void Main(string[] args)
        {
            MyData myData = new MyData() { MyDataMember = "dataMember" };
            Debug.WriteLine(JsonSerializer.ToString(myData));
        }
    }
}

[ahsonkhan]

Is there a particular reason why the new JsonPropertyName attribute won't work for your scenario?

[abelykh0]

We have tens of thousand lines of code and would like to replace Newtonsoft.Json with the new functionality.

[jjrdk]

+1 for sticking with an existing API.

[hmqgg]

Is there a particular reason why the new JsonPropertyName attribute won't work for your scenario?

For example, if we build a Blazor app, and ofc we'd like to make JSON models shared between our server and client to keep them consistent, but on the client side (i.e. Blazor project), we can't use System.Text.Json due to the runtime restrictions so we can't use JsonPropertyName.

What's more, many existing projects now use DataContract/DataMember attributes because it's common and most of JSON libs respect it.

I knew that now it's life after WCF, and we'd better not use these attributes introduced by WCF since it's nearly EoS. But we need attributes that could describe JSON models across so many JSON libs and runtime.

[kucint]

there is currently no replacement for [DataMember(EmitDefaultValue)] in System.Text.Json.

[jjrdk]

@ahsonkhan Can you explain why it is necessary to create a new attribute only for json serialization? What if I also need to serialize to other formats? Should I now decorate my type with additional attributes?

Why not use the existing common attribute?

[stephanharmse]

@jjrdk, I agree. It seems logical to abstract the serialization decorations to allow for the serializing and deserializing in multiple formats (based on request Accept headers for example).

[layomia]

Closing as duplicate - this falls under the ask to support types from System.Runtime.Serialization: https://github.com/dotnet/corefx/issues/38758.

[Tiedye]

Should this be reopened as the conclusion of #29975 was to make individual issues for individual features, which this is.