MicroElements.NSwag.FluentValidation 7.2.1

• net8.0

  • MicroElements.OpenApi.FluentValidation (>= 7.2.1)
  • NJsonSchema (>= 11.3.2)
  • NSwag.Generation (>= 14.4.0)

• net9.0

  • MicroElements.OpenApi.FluentValidation (>= 7.2.1)
  • NJsonSchema (>= 11.3.2)
  • NSwag.Generation (>= 14.4.0)

$# 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

# Changes in 7.1.11
- Fixed: a DTO shared between a flattened `[FromQuery]`/`[AsParameters]` binding and a request body (`[FromBody]`/`[FromForm]`) in the same document could lose its FluentValidation rules, and the emitted document could contain a `$ref` to a removed component (Issue #226). net10.0 target only
 - Root cause: the Issue #180 cleanup left the container type "reserved-but-removed" in Swashbuckle's `SchemaRepository` (component removed, internal reserved-id kept). The 7.1.10 fix (#223) recovered the schema for *reading* constraint values, but a later `[FromBody]`/`[FromForm]` operation binding the same type made Swashbuckle emit a `$ref` to a component that no longer exists (confirmed empirically), and rules applied on the recovered throwaway instance never reached the document
 - Fix (net10.0 / Swashbuckle 10.x): the Issue #180 cleanup now heals the repository state via `SchemaRepository.ReplaceSchemaId` (public API since Swashbuckle 10.1.0) before removing a side-effect schema — the reservation is cleared together with the component, so the next operation binding the same type regenerates a full component and the rules reach the real document object. `SwashbuckleSchemaProvider` tracks `Type → schemaId` for every `GetSchemaForType` call (including the Issue #209 ancestor walk) to make the healing possible
 - net8.0/net9.0 keep the 7.1.10 behavior: they pin Swashbuckle 8.1.1 where `ReplaceSchemaId` does not exist, and bumping the minimum would force the Microsoft.OpenApi 2.x breaking change on consumers. The throwaway recovery from #223 remains as a safety net on all targets
 - Thanks to @jgarciadelanoceda for suggesting the `ReplaceSchemaId` approach

# Changes in 7.1.10
- Fixed: the same `[FromQuery]`/`[AsParameters]` DTO shared by more than one endpoint lost its FluentValidation rules on every endpoint after the first (Issue #223)
 - `FluentValidationOperationFilter` runs once per operation. The Issue #180 cleanup removes the temporary container schema from `SchemaRepository.Schemas`, but Swashbuckle keeps the type in its internal reserved-ids map, which the cleanup does not touch. For the 2nd+ endpoint, `GetSchemaForType` → `GenerateSchema` then returns a bare `$ref` (no `Properties`) and the schema is no longer in `Schemas`, so the "has properties" guard was skipped and no rules were applied. Only reproduces with the default `RemoveUnusedQuerySchemas = true`
 - Fix: in `SwashbuckleSchemaProvider.GetSchemaForType`, when the returned schema has no properties and the id is absent from the shared repository (the reserved-but-removed state), the concrete schema is recovered by generating it into a throwaway `SchemaRepository`. Fully isolated — it never mutates the shared repository or its reserved-id state — so the Issue #180 cleanup and all other `OperationFilter` behavior (required marking #209, nested `[FromQuery]` #211/#213, request bodies, #216) are preserved

# Changes in 7.1.9
- Fixed: numeric bounds from `short`/`byte`/`ushort`/`uint`/`ulong`/`sbyte`-typed rules were silently dropped (Issue #222)
 - `IsNumeric` in the shared core (`MicroElements.OpenApi.FluentValidation`) only recognized `int`/`long`/`float`/`double`/`decimal`/`BigInteger`, so a `Between`/`Comparison` rule whose bound was a small integer type (e.g. `InclusiveBetween((short)1, (short)99)`) matched but produced no `minimum`/`maximum` — even though the generator emits `"type": "integer"` for the property. This could not be worked around at the validator definition site because those rule overloads only accept bounds of the property's own type
 - Fix: `IsNumeric` now recognizes all integer primitives (`sbyte`/`byte`/`short`/`ushort`/`int`/`uint`/`long`/`ulong`) in addition to the floating/decimal/`BigInteger` types; `NumericToDecimal` already converted them all. One change in the shared core fixes all three providers (Swashbuckle, NSwag, and the native `Microsoft.AspNetCore.OpenApi` transformer)


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