Fix duplicate serialization of virtual properties with JsonPropertyName on base class #122842

Copilot · 2026-01-03T21:55:31Z

Original prompt

This section details on the original issue you should resolve

<issue_title>System.text.json serializes virtual property decorated with JsonPropertyName attribute twice.</issue_title>
<issue_description>### Description

System.text.json serializes property decorated with JsonPropertyName attribute in the base class is recording 2 records in the output json , one with property name as key and a second with name specified in the attribute.

Reproduction Steps
Console.WriteLine(JsonSerializer.Serialize(new Derived()));

public class Base
{
    [JsonPropertyName("test")]
    public virtual string Id { get => "base"; set { } }
}

public class Derived : Base
{
    public override string Id { get => "derived"; set { } }
}
Expected behavior

only single entry with name specified in the JsonPropertyName should be adde to json.

Actual behavior

{"Id":"derived","test":"derived"} -> added twice with different names.

Regression?

We have seen this since the initial version.

Known Workarounds

I see two possible workarounds:

Try using the base type as the generic parameter when creating your container object. Unlike Json.NET, STJ is sensitive when it comes to what type is being declared statically at the serialization callsite, or

Replicate the JsonPropertyName property in the overrides. It's more boilerplate, but at least it's the best way to get the desired behavior while we ship a fix.

Configuration

.NET 7

Other information

No response</issue_description>

Comments on the Issue (you are @copilot in this section)
@ Tagging subscribers to this area: @dotnet/area-system-text-json, @gregsdennis See info in [area-owners.md](https://github.com/dotnet/runtime/blob/main/docs/area-owners.md) if you want to be subscribed.

Issue Details

Description

System.text.json serializes property decorated with JsonPropertyName attribute in the base class is recording 2 records in the output json , one with property name as key and a second with name specified in the attribute.

Reproduction Steps

Console.WriteLine(JsonSerializer.Serialize(new Derived()));

public class Base
{
[JsonPropertyName("test")]
public virtual string Id { get => "base"; set { } }
}

public class Derived : Base
{
public override string Id { get => "derived"; set { } }
}

Expected behavior

only single entry with name specified in the JsonPropertyName should be adde to json.

Actual behavior

{"Id":"derived","test":"derived"} -> added twice with different names.

Regression?

We have seen this since the initial version.

Known Workarounds

I see two possible workarounds:

Try using the base type as the generic parameter when creating your container object. Unlike Json.NET, STJ is sensitive when it comes to what type is being declared statically at the serialization callsite, or

Replicate the JsonPropertyName property in the overrides. It's more boilerplate, but at least it's the best way to get the desired behavior while we ship a fix.

Configuration

.NET 7

Other information

No response

Author: alexaloni

Assignees: -

Labels:
area-System.Text.Json

Milestone: -

@eiriktsarpalis I can reproduce in .NET 8. This falls under the same umbrella of issues described in https://github.com//issues/73255, namely it concerns attribute resolution of virtual properties. We should try to address all these issues in unison, although it would admit the probability of breaking changes.
In the meantime, you could try the following workarounds:

Serialize the value using the base type as the generic parameter: JsonSerializer.Serialize<Base>(new Derived()); or

Apply the same JsonPropertyName attribute to the overridden property.</comment_new>

Fixes System.text.json serializes virtual property decorated with JsonPropertyName attribute twice. #92780

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

…me on base class When a virtual property with [JsonPropertyName] on the base class is overridden in a derived class without the attribute, the property was being serialized twice with different JSON names (once from base class's attribute, once from derived class). The fix tracks virtual properties by their CLR member name during property resolution, so that when processing base class properties, we can detect if they have already been overridden by a derived class property - even when the JSON property names differ. This affects both the runtime (DefaultJsonTypeInfoResolver) and the source generator (JsonSourceGenerator). Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com>

Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com>

Copilot

Pull request overview

This PR fixes a bug where virtual properties with [JsonPropertyName] on a base class were serialized twice when overridden in a derived class without the attribute. The root cause was that property conflict resolution only tracked properties by JSON name, so when the derived override lacked the attribute, the different JSON names ("Id" vs "test") prevented collision detection.

Key Changes

Added OverriddenVirtualProperties dictionary to track virtual properties by CLR member name
Added early-exit check in AddPropertyWithConflictResolution to detect virtual property overrides even when JSON names differ
Applied the same fix to both runtime (JsonTypeInfo.cs) and source generator (JsonSourceGenerator.Parser.cs)
Set IsVirtual property in CreatePropertyInfoCore for source-generated metadata
Added comprehensive tests covering the bug scenario and related edge cases

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
src/libraries/System.Text.Json/src/System/Text/Json/Serialization/Metadata/JsonTypeInfo.cs	Added `OverriddenVirtualProperties` dictionary to PropertyHierarchyResolutionState and implemented virtual property override detection logic in `AddPropertyWithConflictResolution`
src/libraries/System.Text.Json/gen/JsonSourceGenerator.Parser.cs	Mirrored the runtime changes in the source generator: added `OverriddenVirtualMembers` dictionary and override detection logic
src/libraries/System.Text.Json/src/System/Text/Json/Serialization/Metadata/JsonMetadataServices.Helpers.cs	Set `IsVirtual` property in `CreatePropertyInfoCore` to ensure source-generated metadata has this flag set correctly
src/libraries/System.Text.Json/tests/Common/PropertyNameTests.cs	Added three test methods covering virtual property scenarios and test class definitions
src/libraries/System.Text.Json/tests/System.Text.Json.SourceGeneration.Tests/Serialization/PropertyNameTests.cs	Registered new test classes in both Metadata and Default source generation contexts

Copilot · 2026-01-04T00:42:30Z

src/libraries/System.Text.Json/tests/Common/PropertyNameTests.cs

+        [Fact]
+        public async Task VirtualPropertyWithJsonPropertyNameOnBaseClass_SerializedOnce()
+        {
+            // Regression test for https://github.com/dotnet/runtime/issues/96998


The comment references issue #96998, but the PR description indicates this fixes issue #92780. Please update the issue number in the comment to match the correct issue being fixed.

@copilot, you can remove the comment about this being a regression test.

Removed in 7954786.

stephentoub · 2026-01-08T14:55:13Z

src/libraries/System.Text.Json/tests/Common/PropertyNameTests.cs

+        [Fact]
+        public async Task VirtualPropertyWithJsonPropertyNameOnBaseClass_SerializedOnce()
+        {
+            // Regression test for https://github.com/dotnet/runtime/issues/96998


@copilot, you can remove the comment about this being a regression test.

stephentoub · 2026-01-08T14:56:15Z

...System.Text.Json/src/System/Text/Json/Serialization/Metadata/JsonMetadataServices.Helpers.cs


            propertyInfo.MemberName = propertyInfoValues.PropertyName;
            propertyInfo.MemberType = propertyInfoValues.IsProperty ? MemberTypes.Property : MemberTypes.Field;
+            propertyInfo.IsVirtual = propertyInfoValues.IsVirtual;


@copilot, was this a bug on its own? Are there other issues that stemmed from this not being copied, or was it otherwise benign? Are there other properties that should be copied but aren't?

Yes, this was a latent bug - IsVirtual was populated by the source generator into JsonPropertyInfoValues<T>.IsVirtual but never copied to JsonPropertyInfo.IsVirtual. This was benign before because IsVirtual on JsonPropertyInfo was only checked when there was a JSON name collision (handled by the existing conflict resolution logic). My fix introduced a new check that uses IsVirtual even when JSON names differ, which exposed the missing copy.

I verified all other properties in JsonPropertyInfoValues<T> are being copied: IsProperty, IsPublic, DeclaringType, PropertyTypeInfo, Converter, Getter, Setter, IgnoreCondition, HasJsonInclude, IsExtensionData, NumberHandling, PropertyName, JsonPropertyName, and AttributeProviderFactory are all handled.

If memory serves IsVirtual is a no-op setting that was added in the public source generator models and never ended up being used.

…meOnBaseClass_SerializedOnce Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com>

eiriktsarpalis · 2026-01-12T12:53:14Z

src/libraries/System.Text.Json/src/System/Text/Json/Serialization/Metadata/JsonTypeInfo.cs

+                // regardless of the JSON property name they use. This handles the case where a derived class
+                // overrides a virtual property but uses a different JSON property name (e.g., due to the base
+                // class having [JsonPropertyName] that the derived class doesn't inherit).
+                if (jsonPropertyInfo.IsVirtual &&


@copilot this check isn't necessary, this class of bugs also impacts shadowed members that aren't necessarily virtual.

@eiriktsarpalis, if a base and a derived type have the same named property but two different json names, they should be different, right?

Removed the IsVirtual check in 171bc5a. The fix now tracks all properties by member name and applies to both virtual overrides and new shadowed members.

if a base and a derived type have the same named property but two different json names, they should be different, right?

From the perspective of C# the property on the base type is rendered inaccessible on the derived type unless a cast is performed. Shouldn't this convention also apply to the JSON contract of the derived type? The presence of a JsonPropertyName shouldn't have any impact on that.

From the perspective of C# the property on the base type is rendered inaccessible on the derived type unless a cast is performed.

They're two completely different properties, with two completely different JSON names; the only happen to have the same C# name, and for that to happen, the developer of the derived type explicitly said they were different by adding new to it. I don't see why the JSON should then pretend that they're the same.

Why? Those are two completely distinct properties, both in expressed developer intent (new) and in JsonPropertyName, which is "bar" in the base and "MyProp" by default in the derived. When it's virtual/override, it's a single property, so you need to factor in relationship between attributes, but when not virtual, they're entirely distinct. The only relationship would be that when there's no attribute, they'd default to conflicting names.

The only relationship would be that when there's no attribute, they'd default to conflicting names.

STJ will give out errors when you have conflicting JSON property names. This doesn't impact shadowed members because they are always being ignored. In other words, STJ has historically treated shadowing members as if they were overrides.

STJ has historically treated shadowing members as if they were overrides.

Well that's unfortunate. We're happy with that? Or we don't like it but it'd be too breaking to change now?

Given that, I'm unclear as to your original comment in this thread. What bugs does removing the IsVirtual check fix?

Well that's unfortunate. We're happy with that? Or we don't like it but it'd be too breaking to change now?

It's not great, but yeah it would be a major breaking change.

What bugs does removing the IsVirtual check fix?

I haven't looked, but given that we haven't used IsVirtual as a distinguishing factor elsewhere in the algorithm I'm concerned about doing it here.

eiriktsarpalis

I'm a bit concerned with targeted fixes touching this logic, as it is particularly prone to introducing breaking changes in the generated serialization contracts. I've created a parent issue tracking all bugs related to this, I think we want to take a more principled approach about what fixes we should be making and how.

Per review feedback, the IsVirtual check was unnecessary since the same bug affects shadowed members using 'new' keyword, not just virtual overrides. The IsOverriddenOrShadowedBy check already handles both cases. Co-authored-by: eiriktsarpalis <2813363+eiriktsarpalis@users.noreply.github.com>

Initial plan

e18d736

Copilot AI assigned Copilot and stephentoub Jan 3, 2026

Copilot started work on behalf of stephentoub January 3, 2026 21:55 View session

Copilot AI and others added 2 commits January 3, 2026 22:36

Add test types to source generation context for PropertyNameTests

74fe4cd

Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com>

Copilot AI changed the title ~~[WIP] Fix double serialization of virtual property with JsonPropertyName~~ Fix duplicate serialization of virtual properties with JsonPropertyName on base class Jan 3, 2026

Copilot AI requested a review from stephentoub January 3, 2026 22:48

Copilot finished work on behalf of stephentoub January 3, 2026 22:48

stephentoub marked this pull request as ready for review January 4, 2026 00:32

Copilot AI review requested due to automatic review settings January 4, 2026 00:32

stephentoub added the area-System.Text.Json label Jan 4, 2026

Copilot started reviewing on behalf of stephentoub January 4, 2026 00:33 View session

Copilot AI reviewed Jan 4, 2026

View reviewed changes

This comment was marked as spam.

Sign in to view

andreanadr approved these changes Jan 6, 2026

View reviewed changes

stephentoub reviewed Jan 8, 2026

View reviewed changes

Copilot started work on behalf of stephentoub January 8, 2026 14:56 View session

Remove regression test comment from VirtualPropertyWithJsonPropertyNa…

7954786

…meOnBaseClass_SerializedOnce Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com>

Copilot finished work on behalf of stephentoub January 8, 2026 15:19

Copilot AI requested a review from stephentoub January 8, 2026 15:19

eiriktsarpalis reviewed Jan 12, 2026

View reviewed changes

Copilot started work on behalf of eiriktsarpalis January 12, 2026 12:53 View session

eiriktsarpalis reviewed Jan 12, 2026

View reviewed changes

Copilot AI requested a review from eiriktsarpalis January 12, 2026 13:03

Copilot finished work on behalf of eiriktsarpalis January 12, 2026 13:03

stephentoub closed this Jan 22, 2026

Author:	alexaloni
Assignees:	-
Labels:	`area-System.Text.Json`
Milestone:	-

Fix duplicate serialization of virtual properties with JsonPropertyName on base class #122842

Fix duplicate serialization of virtual properties with JsonPropertyName on base class #122842

Conversation

Copilot AI commented Jan 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Reproduction Steps

Expected behavior

Actual behavior

Regression?

Known Workarounds

Configuration

Other information

Comments on the Issue (you are @copilot in this section)

Description

Reproduction Steps

Expected behavior

Actual behavior

Regression?

Known Workarounds

Configuration

Other information

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Key Changes

Reviewed changes

Uh oh!

Copilot AI Jan 4, 2026

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 8, 2026

Choose a reason for hiding this comment

Uh oh!

This comment was marked as spam.

Uh oh!

This comment was marked as spam.

Uh oh!

This comment was marked as spam.

Uh oh!

This comment was marked as spam.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 8, 2026

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 12, 2026

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

stephentoub Jan 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

eiriktsarpalis left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Copilot AI commented Jan 3, 2026 •

edited

Loading

stephentoub Jan 12, 2026 •

edited

Loading