MicroElements.Swashbuckle.FluentValidation 7.2.4

• net10.0

  • MicroElements.OpenApi.FluentValidation (>= 7.2.4)
  • Swashbuckle.AspNetCore.SwaggerGen (>= 10.2.1)

• net8.0

  • MicroElements.OpenApi.FluentValidation (>= 7.2.4)
  • Swashbuckle.AspNetCore.SwaggerGen (>= 8.1.1)

• net9.0

  • MicroElements.OpenApi.FluentValidation (>= 7.2.4)
  • Swashbuckle.AspNetCore.SwaggerGen (>= 8.1.1)

$# Changes in 7.2.4
- Fixed: `MicroElements.AspNetCore.OpenApi.FluentValidation` could lose string `minLength` and `maxLength` constraints when a custom JSON converter left the property's schema type unset (Issue #238, regression in 7.2.3). Length rules now fall back to the FluentValidation target's CLR string type only when the schema type is absent, preserving explicit schema types and the non-string `ChildRules` safeguards. A later transformer can restore the schema type without requiring registration order changes.
- Added regression coverage for string converters, late type restoration, identity child rules, explicit non-string schema types, and untyped non-string values.

# 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