[API Proposal]: Attribute on Types to opt-out of default Serialization/Binding behavior when they implement Collection Interfaces

[fitdev]

Background and motivation

I have come across at least 2 cases in DotNet 6 where Serialization and Deserialization in System.Text.Json as well as Microsoft.Extensions.Configuration.Binder were producing incorrect results by treating in a special way types that implement various collection interfaces (IList<T> and IEnumerable<T>) in my case.

While the current behavior is absolutely fine for most cases, in some situations where user types implement the aforementioned interfaces, this behavior is wrong. For example, if a type implements IList<T> but has some additional public properties, it will still be serialized by System.Text.Json effectively as a List<T> without the additional properties.

My other case was the incorrect treatment of my custom type by Microsoft.Extensions.Configuration.Binder because it implemented IEnumerable<T>, which was fixed fortunately, but still highlights the importance of this issue for other current and future binding / (de)serialization scenarios.

API Proposal

I cannot recommend anything particular at this point. But ideally an attribute with/without some options would suffice:

[AttributeUsage(AttributeTargets.Type | AttributeTargets.Module | AttributeTargets.Assembly, AllowMultiple = false, Inherited = true)]
public class OptOutOfDefaultCollectionSerializationAndBindingBehavior : Attribute {

}

API Usage

[OptOutOfDefaultCollectionSerializationAndBindingBehavior]
public class MyFancyType : IList<string> {

}

Alternative Designs

No response

Risks

No response

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[ghost]

Tagging subscribers to this area: @dotnet/area-system-text-json
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Background and motivation

I have come across at least 2 cases in DotNet 6 where Serialization and Deserialization in System.Text.Json as well as Microsoft.Extensions.Configuration.Binder were producing incorrect results by treating in a special way types that implement various collection interfaces (IList<T> and IEnumerable<T>) in my case.

While the current behavior is absolutely fine for most cases, in some situations where user types implement the aforementioned interfaces, this behavior is wrong. For example, if a type implements IList<T> but has some additional public properties, it will still be serialized by System.Text.Json effectively as a List<T> without the additional properties.

My other case was the incorrect treatment of my custom type by Microsoft.Extensions.Configuration.Binder because it implemented IEnumerable<T>, which was fixed fortunately, but still highlights the importance of this issue for other current and future binding / (de)serialization scenarios.

API Proposal

I cannot recommend anything particular at this point. But ideally an attribute with/without some options would suffice:

[AttributeUsage(AttributeTargets.Type | AttributeTargets.Module | AttributeTargets.Assembly, AllowMultiple = false, Inherited = true)]
public class OptOutOfDefaultCollectionSerializationAndBindingBehavior : Attribute {

}

API Usage

[OptOutOfDefaultCollectionSerializationAndBindingBehavior]
public class MyFancyType : IList<string> {

}

Alternative Designs

No response

Risks

No response

Author:	fitdev
Assignees:	-
Labels:	api-suggestion, area-System.Text.Json, untriaged
Milestone:	-

[eiriktsarpalis]

Duplicate of #1808.

We likely won't be using an opt-out attribute, instead we'd let users opt in to different converter strategies using the JsonConverterAttribute.

[fitdev]

It's not about just System.Text.Json though, as I mentioned at the beginning. It relates to Microsoft.Extensions.Configuration.Binder and very likely other binders and serializers too. So having a single attribute that alerts various Binders/Serializers to how types implementing Collection interfaces should be handled may be a better option.

[eiriktsarpalis]

From the System.Text.Json perspective, we are intentionally not honoring any of the common System.Runtime.Serialization attributes, using bespoke attribute declarations instead (cf. #29975). So it's unlikely STJ would honor a new common attribute, and even more unlikely that any of the older serializers would honor it either, given that many of them are relegated to maintenance mode.

[fitdev]

Right, but there are many common binding scenarios (there was even some talk of unifying binder story between ASP.NET, Configuration, CommandLine, etc., and in there such an attribute, or generalized version of it would still be useful. SO it is not just about Serializers either.