Support type-level JsonIgnoreCondition via [JsonIgnore] on classes, structs, and interfaces#124646
Support type-level JsonIgnoreCondition via [JsonIgnore] on classes, structs, and interfaces#124646
Conversation
|
Tagging subscribers to this area: @dotnet/area-system-text-json |
…n resolver, source generator) Co-authored-by: eiriktsarpalis <[email protected]>
…on value types Co-authored-by: eiriktsarpalis <[email protected]>
…dd inheritance and deserialization tests Co-authored-by: eiriktsarpalis <[email protected]>
| } | ||
|
|
||
| if (attributeType?.ContainingAssembly.Name == SystemTextJsonNamespace && | ||
| attributeType.ToDisplayString() == JsonIgnoreAttributeFullName) |
There was a problem hiding this comment.
@copilot rather than allocating a full string every type the attribute gets compared, use the existing pattern in KnownSymbols.cs (or whatever it's called) where the attribute symbol is cached for the current compilation.
There was a problem hiding this comment.
Switched to using SymbolEqualityComparer.Default.Equals(attributeType, _knownSymbols.JsonIgnoreAttributeType) with a cached JsonIgnoreAttributeType property added to KnownTypeSymbols.cs, matching the pattern used by other attribute types like JsonDerivedTypeAttributeType. Commit 1f73332.
| else if (namedArgs.Length == 1 && | ||
| namedArgs[0].Value.Type?.ToDisplayString() == JsonIgnoreConditionFullName) | ||
| { | ||
| typeIgnoreCondition = (JsonIgnoreCondition)namedArgs[0].Value.Value!; |
There was a problem hiding this comment.
What happens if the JsonIgnoreCondition is Always on the type level? Surely that would be invalid configuration? Add a diagnostic, a source generator unit test and a testing covering runtime behavior for both the generator and relection-based serializers.
There was a problem hiding this comment.
Added handling for JsonIgnoreCondition.Always at the type level:
- Reflection path: throws
InvalidOperationException(reusingSR.DefaultIgnoreConditionInvalid), consistent withJsonSerializerOptions.DefaultIgnoreConditionbehavior - Source generator: emits
SYSLIB1226warning diagnostic and ignores the attribute (resetstypeIgnoreConditionto null) - Source gen unit test:
JsonIgnoreConditionAlwaysOnTypeWarnsinJsonSourceGeneratorDiagnosticsTests.cs - Runtime tests:
JsonIgnoreCondition_TypeLevel_Always_ThrowsInvalidOperation(virtual in base, overridden in source gen tests to verify properties serialize normally when the attribute is ignored)
Commit 1f73332.
…YSLIB1226 diagnostic Co-authored-by: eiriktsarpalis <[email protected]>
| </Suppression> | ||
| <Suppression> | ||
| <DiagnosticId>CP0015</DiagnosticId> | ||
| <Target>T:System.Text.Json.Serialization.JsonIgnoreAttribute:[T:System.AttributeUsageAttribute]</Target> |
There was a problem hiding this comment.
@copilot this is still causing API compatibility errors. Please address accordingly.
There was a problem hiding this comment.
Added CompatibilitySuppressions.xml in src/libraries/System.Text.Json/src/ for package validation (CP0015 suppression for JsonIgnoreAttribute's AttributeUsageAttribute change across net10.0, net462, and netstandard2.0 TFMs). The existing suppression in ApiCompatBaseline.NetCoreAppLatestStable.xml covers the shared framework API compat check, but the package-level validation also needs its own suppression file since System.Text.Json ships as a multi-TFM NuGet package. Commit fc730c9.
…tion Co-authored-by: eiriktsarpalis <[email protected]>
|
Just as a heads up, I was blocked by some firewall rules while working on your feedback. Expand below for details. Warning Firewall rules blocked me from connecting to one or more addresses (expand for details)I tried to connect to the following addresses, but was blocked by firewall rules:
If you need me to access, download, or install something from one of these locations, you can either:
|
Description
[JsonIgnore(Condition = ...)]can now be applied at the type level to set a defaultJsonIgnoreConditionfor all properties and fields, eliminating per-property duplication:Property-level
[JsonIgnore]overrides the type-level setting.WhenWritingNullis silently skipped for non-nullable value types, matchingJsonSerializerOptions.DefaultIgnoreConditionsemantics.JsonIgnoreCondition.Alwaysis rejected at the type level as invalid configuration — the reflection path throwsInvalidOperationException, and the source generator emitsSYSLIB1226warning diagnostic and ignores the attribute.Changes
JsonIgnoreAttributeAttributeUsageto includeClass | Struct | Interface, with API compat suppressions for theAttributeUsagechange in both the shared framework baseline (ApiCompatBaseline.NetCoreAppLatestStable.xml) and the package-level baseline (CompatibilitySuppressions.xmlfornet10.0,net462,netstandard2.0)DefaultJsonTypeInfoResolver.Helpers.cs): Falls back to type-level[JsonIgnore]when no member-level attribute is present. UsestypeInfo.Type(root serialized type) so type-level attributes on derived classes apply to inherited base-class properties. ThrowsInvalidOperationExceptionforJsonIgnoreCondition.Alwaysat the type level.JsonSourceGenerator.Parser.cs): Reads type-level[JsonIgnore]inProcessTypeCustomAttributesusing cachedJsonIgnoreAttributeTypesymbol fromKnownTypeSymbols.cs, threads it through to property parsing as a fallback. EmitsSYSLIB1226diagnostic forJsonIgnoreCondition.Alwaysat the type level.SYSLIB1226diagnostic descriptor, resource strings (including XLF translations), and updatedlist-of-diagnostics.mdWhenWritingNull,WhenWritingDefault,Always(invalid config), property-level override, struct, inheritance, and deserialization scenarios across both reflection and source gen paths. Includes source generator unit test for theSYSLIB1226diagnostic.Original prompt
JsonIgnoreCondition's on the type level #108231💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.