[release/11.0] Add message template formatting to DataAnnotations validation attributes - #132853
Open
github-actions[bot] wants to merge 1 commit into
Open
[release/11.0] Add message template formatting to DataAnnotations validation attributes#132853github-actions[bot] wants to merge 1 commit into
github-actions[bot] wants to merge 1 commit into
Conversation
…tes (#132764) ## Summary Adds the approved `ValidationAttribute.FormatMessage` API so callers can supply externally localized composite-format strings while each validation attribute remains responsible for providing its placeholder arguments. ## Changes - Add `ValidationAttribute.FormatMessage([StringSyntax("CompositeFormat")] string format, string name)`. - Route the base `FormatErrorMessage` implementation through the new method. - Add overrides for `CompareAttribute`, `FileExtensionsAttribute`, `LengthAttribute`, `MaxLengthAttribute`, `MinLengthAttribute`, `RangeAttribute`, `RegularExpressionAttribute`, and `StringLengthAttribute`. - Preserve existing placeholder ordering and `CurrentCulture` formatting. - Add coverage for supplied formats, virtual dispatch, culture-sensitive formatting, invalid formats, and null arguments. Existing `FormatErrorMessage` behavior remains unchanged. ## Testing - `dotnet build` — succeeded with 0 warnings and 0 errors. - `dotnet build /t:test .\tests\System.ComponentModel.Annotations.Tests.csproj` — 1,008 passed, 0 failed, 0 skipped. Fixes #132605 > [!NOTE] > This pull request description was generated with GitHub Copilot. --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 524df8bb-0555-4425-b73f-bc8340d0dfc2
|
Azure Pipelines: Successfully started running 3 pipeline(s). 13 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run. |
Contributor
|
Tagging subscribers to this area: @dotnet/area-system-componentmodel-dataannotations |
artl93
approved these changes
Aug 27, 2026
artl93
left a comment
artl93
left a comment
Member
There was a problem hiding this comment.
completing a new feature. approved.
This was referenced Aug 28, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Backport of #132764 to
release/11.0.API proposal: #132605
/cc @jeffhandley @oroztocil
Customer Impact
.NET 11 introduces first-class localization support in
Microsoft.Extensions.Validation, consumed by Minimal APIs and Blazor. However, DataAnnotations does not expose a shared way for a caller to supply a localized message template while allowing each validation attribute to provide its own placeholder arguments.Without this change, the .NET 11 localization implementation must retain generated per-attribute formatting switches, other hosts cannot reuse the same primitive, and duplicated formatting knowledge can diverge from the real attribute behavior. One existing example is
FileExtensionsAttribute, where the attribute supplies normalized, dot-prefixed extensions while duplicated upper-layer formatters have supplied the raw property value.The customer scenario has been requested repeatedly:
This backport adds the API-approved
ValidationAttribute.FormatMessageprimitive and preserves the attribute-specific formatting contract for built-in attributes and Options source-generated replicas.We believe this meets the .NET 11 RC2 bug bar as:
Regression
This is not a regression from .NET 10. The API and the first-class
Microsoft.Extensions.Validationlocalization scenario are new in .NET 11.Testing
On
main:System.ComponentModel.Annotationsbuilt successfully.System.ComponentModel.Annotations.Tests: 1,008 passed, 0 failed.Microsoft.Extensions.Optionsbuilt successfully.Microsoft.Extensions.Options.Tests: 177 net11 tests and 158 net481 tests passed.Microsoft.Extensions.Options.SourceGeneration.Unit.Tests: 103 net11 tests and 82 net481 tests passed, with one expected conditional skip.Microsoft.Extensions.Options.SourceGeneration.Tests: 68 net11 tests and 68 net481 tests passed.The same component tests and release-branch CI will validate the backport on
release/11.0.Risk
Low-to-moderate.
The change adds an API-reviewed public virtual method and explicit overrides on the built-in attributes that require additional format arguments. It is additive and removes no existing surface.
Existing
FormatErrorMessagebehavior, argument ordering, andCurrentCultureformatting remain unchanged. The Options source generator emits matching overrides only when the target compilation exposes the new API, leaving down-level and .NET Framework output unchanged.The main implementation risks are public virtual dispatch and source-generator parity. These are mitigated by:
No package references, dependencies, or package-authoring project settings change.
Note
This pull request description was generated with GitHub Copilot.