[Validation] Use [JsonPropertyName] for display name

[martincostello]

[Validation] Use [JsonPropertyName] for display

Use [JsonPropertyName("{value}")] for the display name.

Description

Use [JsonPropertyName("{value}")] for the display name if [Display(Name = "{value}") is not specified instead of the property's name.

I didn't make any changes to use it for the name due to #62341 (comment).

Contributes to #63290.

[Copilot]

Pull Request Overview

This PR enhances the validation generator to use JsonPropertyName attributes for display names when Display attributes are not present. This improves the user experience by providing more meaningful display names in validation error messages when JSON property names are specified.

• Modifies the type parser to check for JsonPropertyName attributes as a fallback when Display attributes are not present
• Updates the ISymbolExtensions to support extracting display names from JsonPropertyName attributes with both named arguments and constructor arguments
• Adds the JsonPropertyNameAttribute to the well-known types for proper attribute detection

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
ValidationsGenerator.TypesParser.cs	Updates display name resolution logic to use JsonPropertyName as fallback after Display attribute
ISymbolExtensions.cs	Enhances GetDisplayName method to handle JsonPropertyName attribute extraction with both named and constructor arguments
WellKnownTypeData.cs	Adds JsonPropertyNameAttribute to the well-known types enumeration and names array
ValidationsGenerator.ComplexType.cs	Adds test case with ComplexTypeWithJsonPropertyName class to verify the new functionality
ValidatableInfoResolver.g.verified.cs	Updates test snapshot to include expected generated code for the JsonPropertyName test case

[marcominerva]

@martincostello, do you mind close and reopen it? I think this is another important fix 😄

[martincostello]

I can't. [Just realised this is my own PR, so I could] If the team aren't actively triaging right now it'll just go stale again in 7 days anyway, so there's not much point. The CI being stale isn't the primary obstacle to this being merged, the team reviewing it is.

[martincostello]

This isn't really a fix either, it's a feature/behaviour change, so wouldn't ship until a .NET 11 preview anyway.

[marcominerva]

Yes, I know that at most it will be part of .NET 11 (sorry if I called it a fix, it was a slip of the tongue 😅), but I still think it's a very useful feature. I hope it will be taken into consideration 😄

[oroztocil]

I think we want to add an extensibility point to ValidateContext (or elsewhere) that would allow consuming frameworks (e.g. MinAPIs vs Blazor) to configure different key/name/message transformations as they need for their use case. This would allow the Validation package to be more framework-agnostic and could transitively simplify implementation for the consuming frameworks (by not needing to take into account unwanted transformations).

JSON-related transformations - which are natural for APIs but unexpected for UI frameworks - might be better registered using such extensibility point.

There is obviously a trade off in how much work is moved from compile-time into run-time. However, considering that previous validation solutions did all of their work during run-time (with caching in some places), I'd argue we have a budget to work with.