MicroElements.Swashbuckle.FluentValidation 7.1.9

• net10.0

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

• net8.0

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

• net9.0

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

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

# Changes in 7.1.8
- Security (Issue #220): closed a transitive high-severity advisory in the published package. `Swashbuckle.AspNetCore.SwaggerGen` on the net10.0 target was bumped `10.0.0` → `10.2.1`, which resolves `Microsoft.OpenApi` to the patched `2.7.5` (was `2.3.0`). This clears **GHSA-v5pm-xwqc-g5wc / CVE-2026-49451** (CWE-674 uncontrolled recursion — a circular `$ref` schema could stack-overflow the OpenAPI reader). The net8.0/net9.0 targets use Swashbuckle 8.1.1 → Microsoft.OpenApi v1 and were never in the advisory range
- Media type & file size validation for `IFormFile` uploads (Issue #216): stable rollup of everything in `7.1.8-beta.1` and `7.1.8-beta.2` below (new File-level rules `.FileContentType()`, `.MaxFileSize()`, `.MinFileSize()`, `.FileSizeBetween()`; Swashbuckle / NSwag / Microsoft.AspNetCore.OpenApi emit multipart `encoding.contentType` and description annotations)

# Changes in 7.1.8-beta.2
- All of `7.1.8-beta.1` below, plus: **Microsoft.AspNetCore.OpenApi** now also emits `encoding.contentType` for the file part (Issue #216) — the `FluentValidationOperationTransformer` writes `requestBody.content["multipart/form-data"].encoding.<part>.contentType` so UIs like Scalar/Swagger UI can show the accepted media types, not just the description. Works on net9.0 (inline form schema) and net10.0 (resolves the whole-body `$ref` component to find the part name)

# Changes in 7.1.8-beta.1
- Added: media type (content type) and file size validation for `IFormFile` uploads (Issue #216)
 - New File-level FluentValidation rules in `MicroElements.OpenApi.FluentValidation` (namespace `MicroElements.OpenApi.FluentValidation.FileUpload`): `.FileContentType(params string[])`, `.MaxFileSize(long)`, `.MinFileSize(long)`, `.FileSizeBetween(long, long)` on `IRuleBuilder<T, IFormFile>`. They both enforce validation at runtime and surface metadata for OpenAPI generation
 - Root cause: rules on nested `IFormFile` members (`RuleFor(x => x.File.Length)` / `RuleFor(x => x.File.ContentType)`) are named `File.Length` / `File.ContentType` and never match the flat schema property `File`, so they were silently dropped; and `Must(...)` is opaque so allowed content types could not be reflected. Use the new File-level rules instead
 - **Swashbuckle**: emits `requestBody.content["multipart/form-data"].encoding.<part>.contentType` (comma-joined allowed types) and appends the allowed types and size limits to the file property `description`. File size is never emitted as `maxLength` (which counts characters, not bytes). Works on net8.0/net9.0 (Microsoft.OpenApi v1, OpenAPI 3.0) and net10.0 (Microsoft.OpenApi v2, OpenAPI 3.1)
 - **NSwag**: a new `FluentValidationOperationProcessor` (`IOperationProcessor`) emits multipart encoding for file parts; the allowed types and size limits are also appended to the file part `description`. Register it alongside the schema processor: `settings.OperationProcessors.Add(serviceProvider.GetService<FluentValidationOperationProcessor>())`. Known NSwag limitation: `OpenApiEncoding.EncodingType` serializes as `encodingType` rather than the OpenAPI-spec `contentType` (through at least NSwag 14.7.x), so the `description` is the guaranteed-visible carrier
 - **Microsoft.AspNetCore.OpenApi**: the allowed types and size limits are appended to the file property `description`, and (since `7.1.8-beta.2`) the allowed types are also emitted as `encoding.contentType` on the multipart media type
 - Purely additive / opt-in: behavior only changes when the new rules are used; no existing document output changes
 - File size has no standard OpenAPI/JSON-Schema byte keyword, so it is documented in the `description` (annotation only; enforcement stays server-side via FluentValidation)

# Changes in 7.1.7
- Fixed: The nested `[FromQuery]` fixes (#209 + #211) now also apply to the native `Microsoft.AspNetCore.OpenApi` transformer and the experimental Swashbuckle DocumentFilter (Issue #213)
 - `FluentValidationOperationTransformer` (package `MicroElements.AspNetCore.OpenApi.FluentValidation`) previously set a nested parameter `required` from the leaf validator alone — ignoring both whether the `SetValidator`/`ChildRules` chain reaches the leaf (#211) and whether every ancestor of the dot-path is required (#209). It now follows the same reachability + ancestor-required rules as the Swashbuckle `OperationFilter`
 - The experimental `FluentValidationDocumentFilter` no longer copies value constraints onto a flattened nested parameter whose nested validation is not wired from the root validator (#211)
 - `GetMethodInfo` now resolves the action method from `ControllerActionDescriptor` (MVC controllers), not only minimal-API endpoint metadata, so the dot-path root type can be resolved for controller actions
 - NSwag is unaffected (it has no `[FromQuery]` parameter flattening)
- Fixed: A validator for a nested type bound via `[FromQuery]` was reflected in the OpenAPI document even when it was **not** wired into the root validator via `SetValidator`/`ChildRules` (Issue #211)
 - `FluentValidationOperationFilter` resolved the leaf container's validator directly from the registry (by `ModelMetadata.ContainerType`), so a nested `NotEmpty()` marked the flattened parameter (e.g. `RequiredSubType.SubProperty`) as `required` even though FluentValidation never validates an unwired child object — the OpenAPI doc claimed `required`, but the API accepted requests without it
 - Fix: for a flattened nested parameter, nested rules are now applied only when the `SetValidator`/`ChildRules` chain from the action's root `[FromQuery]` validator actually reaches the leaf container; otherwise the parameter is left unconstrained, matching runtime behavior
 - When the root container type cannot be resolved, prior behavior is preserved (no regression for existing nested-parameter scenarios)
 - Behavioral change: when no validator is registered for the root `[FromQuery]` type (only a leaf/child validator is registered), a flattened nested parameter is now left unconstrained — matching runtime, where no validation runs without a root validator
- Fixed: A required leaf property inside an **optional** nested type bound via `[FromQuery]` was wrongly marked as a required parameter (Issue #209)
 - The 7.1.1 fix (Issue #162) made nested `[FromQuery]` validation match the leaf property name, but `FluentValidationOperationFilter` then set `required` based solely on the leaf type, ignoring whether the ancestor segment of the dot-path was optional
 - Because two nested properties of the same leaf type share one schema/validator (e.g. `OptionalSubType.SubProperty` and `RequiredSubType.SubProperty`), a `NotEmpty()` on the leaf marked **both** flattened parameters as required
 - Fix: a flattened nested parameter is now marked `required` only when **every** ancestor segment of the dot-path is required — resolved from the action's root `[FromQuery]` type, combining the native schema `required` (e.g. the C# `required` modifier) with FluentValidation `NotNull`/`NotEmpty` rules
 - Value constraints (e.g. `minLength`) still apply to an optional nested parameter when it is provided
 - When the root container type cannot be resolved, prior behavior is preserved (no regression for existing nested-parameter scenarios)


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