MicroElements.OpenApi.FluentValidation 7.3.0-beta.1

• net10.0

  • FluentValidation (>= 12.0.0)

• net11.0

  • FluentValidation (>= 12.0.0)

• net8.0

  • FluentValidation (>= 12.0.0)
  • Microsoft.Extensions.Logging.Abstractions (>= 9.0.5)
  • Microsoft.Extensions.Options (>= 9.0.5)

• net9.0

  • FluentValidation (>= 12.0.0)

$# Changes in 7.3.0-beta.1
- Security: the native ASP.NET Core OpenAPI adapter now requires `Microsoft.OpenApi` 2.7.5 or later on net10, excluding versions affected by GHSA-v5pm-xwqc-g5wc.
- Added: `net11.0` assets for `MicroElements.OpenApi.FluentValidation` and `MicroElements.AspNetCore.OpenApi.FluentValidation`, using .NET 11 RC3 dependencies. The native ASP.NET Core adapter supports OpenAPI 3.2 and explicitly selected OpenAPI 3.1, with runtime and build-time generation coverage.
- Compatibility: Swashbuckle and NSwag retain their existing package targets and generator dependencies. Their existing assets were tested in .NET 11 hosts. This beta does not include the separate Swashbuckle 11 / Microsoft.OpenApi 3.x experiment.
- Behavior: on .NET 11, float and double validation bounds can appear with additional decimal digits in generated schemas because of runtime numeric conversion changes. The library preserves the runtime values without additional rounding; existing .NET 8–10 behavior is unchanged.
- Development: added a shared .NET 11 RC3 SDK baseline with `rollForward: latestFeature`. Package consumers do not need this SDK unless targeting .NET 11. Automatic package upload remains disabled; beta publication requires a manually triggered workflow on the beta tag.

# Changes in 7.2.3
- Fixed: constraints inside `ChildRules(child => child.RuleFor(x => x).Matches(...).DependentRules(...))` were missing from the parent property's OpenAPI schema. Identity child rules now contribute their constraints to the owning property (or collection item), including nested identity validators, while honoring rule/component filters and conditional-rule settings. The fix is shared by Swashbuckle, NSwag, and Microsoft.AspNetCore.OpenApi. Runtime validation is unchanged; schema generation does not execute `Must` predicates or repository lookups, and does not infer constraints from `DependentRules`.
- Fixed: identity child `NotNull`/`NotEmpty` rules preserve the owning property's nullability and optionality, matching FluentValidation's null-skipping child adapters. Non-empty string/array constraints and explicit parent presence rules are preserved.

# Changes in 7.2.2
- Fixed: `MicroElements.AspNetCore.OpenApi.FluentValidation` did not apply FluentValidation rules to a `[FromForm]` DTO bound by an **MVC controller** action (Issue #232, follow-up to the Swashbuckle-only #170 fix)
 - Root cause: MVC `ApiExplorer` flattens a controller's `[FromForm]` complex parameter into one form field per property, so `Microsoft.AspNetCore.OpenApi` builds the request body as an **inline** schema from those descriptions and never asks for the DTO's `JsonTypeInfo` — `FluentValidationSchemaTransformer` therefore never saw the type. Minimal API form bodies are not flattened and were never affected
 - Fix: `FluentValidationOperationTransformer` now applies the DTO's rules to the inline form schema for both `multipart/form-data` and `application/x-www-form-urlencoded`. The flattening is detected via `ModelMetadata.ContainerType` on the form-bound parameter descriptions, so a minimal API body — which the schema transformer already owns — is never touched twice
 - Property keys are taken verbatim from the schema, because a flattened form field is named after the model binder (`Name`, not `name`); the validator-side match stays name-insensitive
 - An action binding more than one form parameter composes its body as an `allOf` of one property bag per parameter; every bag is now constrained, and each bag is paired with the parameter that owns its fields — including the parameters the action binds directly (a loose scalar, array or `IFormFile`), which get a bag of their own but no rules. Without that pairing a DTO could be pulled into a foreign bag by a single coinciding field name and lose the constraints on its own bag
 - `encoding.contentType` (Issue #216) is now also emitted when the file part sits inside such an `allOf` bag
 - Dotted keys (`Inner.City`, ApiExplorer's binding path for a nested complex property) are skipped: the name matcher ignores separators, so such a key would otherwise inherit the rules of an unrelated root property named `InnerCity`. Nested form fields remain unsupported, matching the Swashbuckle form path
 - Issue #216 `encoding.contentType` is unchanged for the shapes it already covered, and now also consults every validator in multi-validator mode (`IsOneValidatorForType = false`) instead of only the first
 - Known limitations on this path (unchanged by this fix): a renamed form field (`[FromForm(Name = "...")]`, or a property renamed by the `INameResolver`) gets no constraints, and on net10 a form part rendered as a `$ref` (`IFormFile`, enums) cannot receive property-level constraints
 - Thanks to @bux for the report

# Changes in 7.2.1
- Fixed: the document-filter pipeline (`UseDocumentFilter = true`) did not apply FluentValidation constraints to aliased operation parameters such as `[FromHeader(Name = "X-Correlation-Id")]` (Issue #230). The constraint copy now uses the resolved schema property key (kebab-case/camelCase/PascalCase aliases) and falls back to the `INameResolver` for renames beyond separators (e.g. `[JsonPropertyName]`) — full parity with the operation filter
- Fixed: a dot in a header name (`[FromHeader(Name = "X.Trace.Id")]` — legal in HTTP) was treated as a nested `[FromQuery]` dot-path (#209/#211) and silently dropped the header's validation rules. Header-bound parameters are now exempt from the dot-path logic in all three parameter pipelines: `FluentValidationOperationFilter`, `FluentValidationDocumentFilter` and the ASP.NET Core `FluentValidationOperationTransformer`. NSwag is unaffected (it has no dot-path parameter logic)
- Fixed: the document filter matched document parameters to `ApiExplorer` descriptions case-sensitively, so options like `DescribeAllParametersInCamelCase` made it skip required-marking and constraint copying. The lookup is now case-insensitive, matching the operation filter
- Thanks to @jgarciadelanoceda for the report and the repro

# Changes in 7.2.0
- Added: the document-filter pipeline is promoted from experimental to a **supported opt-in** (`RegistrationOptions.UseDocumentFilter`, default `false`). The document filter processes the whole document at once and performs the unused-query-schema cleanup once at the end, so per-operation shared-DTO state issues (#223/#226) cannot occur in this pipeline — **on all target frameworks**, including net8.0/net9.0 where the 7.1.11 healing API is unavailable
 - Full functional parity with the default schema + operation filter pipeline: required-marking with the whole-dot-path check (#209), request bodies and `encoding.contentType` for `[FromForm]` (#216), multi-validator support, `allOf`/`oneOf`/`anyOf` traversal, `$ref` preservation for unmodified properties (#198, net10.0), and every operation of a multi-verb path is now processed (previously only the first)
 - The #209 and #216 logic is extracted into internal components shared by both pipelines, so they cannot drift apart
 - Robustness: the filter no longer fails the whole document generation on a throwing validator (top-level try/catch), falls back to `ServiceProviderValidatorRegistry` like the sibling filters, honors an injected `IFluentValidationRuleProvider` (new optional constructor parameter, appended last — source-compatible), and had its dead code, logging and nullability issues cleaned up. Behavior note: constructing `FluentValidationDocumentFilter` with neither `validatorRegistry` nor `serviceProvider` now throws `ArgumentNullException` (matching the sibling filters) instead of silently producing a filter that applies no rules; the DI registration path is unaffected
 - On net10.0 the cleanup also heals Swashbuckle's reserved-ids for processed container types (`SchemaRepository.ReplaceSchemaId`), so custom document filters running afterwards can regenerate them
 - `ExperimentalUseDocumentFilter` still works as an `[Obsolete]` alias forwarding to `UseDocumentFilter`
 - The default pipeline is unchanged; a future major version may switch the default
 - `samples/MinimalApi` now runs on the document-filter pipeline; README documents the option and its caveats


Full release notes can be found at: https://github.com/micro-elements/MicroElements.Swashbuckle.FluentValidation/blob/master/CHANGELOG.md