MicroElements.Swashbuckle.FluentValidation 7.1.7-beta.2

• net10.0

  • MicroElements.OpenApi.FluentValidation (>= 7.1.7-beta.2)
  • Swashbuckle.AspNetCore.SwaggerGen (>= 10.0.0)

• net8.0

  • MicroElements.OpenApi.FluentValidation (>= 7.1.7-beta.2)
  • Swashbuckle.AspNetCore.SwaggerGen (>= 8.1.1)

• net9.0

  • MicroElements.OpenApi.FluentValidation (>= 7.1.7-beta.2)
  • Swashbuckle.AspNetCore.SwaggerGen (>= 8.1.1)

$# Changes in 7.1.7
- 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)

# Changes in 7.1.6
- Fixed: `$ref` still replaced with an inline copy (and the child component left orphaned) when nested object constraints come from `ChildRules` or an inline child validator (Issue #198, comment 4601720562)
 - The 7.1.3 fix restored unmodified `$ref`s, but when the nested type had no standalone validator its component schema gained its `Required` only after the parent's inline snapshot, so the stale `Required` diverged and defeated the restore check — leaving an inline copy and an orphaned component
 - Fix: the `Required` comparison in `HasValidationConstraintChanges` is now directional — restoration is only blocked when the inline copy carries a required entry the component lacks
 - `SetValidator` (with a standalone child validator) was already correct; `BigInteger`/enum per-model constraints (Issues #146/#176) continue to work
- Added: `ConditionalRulesMode` option to control how `.When()`/`.Unless()` conditional rules are handled during schema generation (Issue #203)
 - `Exclude` (default): conditional rules are excluded from the schema (backward-compatible, existing behavior)
 - `Include`: conditional rules are included in the schema (useful when `.When()` is a null-guard and constraints should still appear)
 - `IncludeWithWarning`: same as `Include` but logs a warning for each conditional rule included
 - Usage: `options.ConditionalRules = ConditionalRulesMode.Include;`
- Fixed: Multiple `.Matches()` rules on one property displayed incorrectly — only the first pattern shown, property duplicated (Issue #204)
 - Multiple patterns were placed into separate `allOf` subschemas, which Swagger UI/Redoc/Scalar collapse, keeping only the first `pattern`
 - Now multiple `.Matches()` rules are combined into a single `pattern` via lookahead assertions (e.g. `(?=[\s\S]*(?:[a-z]))(?=[\s\S]*(?:[A-Z]))`), preserving `.Matches()` semantics and rendering correctly
 - Applied to all providers: Swashbuckle, `MicroElements.AspNetCore.OpenApi.FluentValidation`, and NSwag (NSwag previously kept only the last pattern)
 - Changed: `SchemaGenerationOptions.UseAllOfForMultipleRules` default `true` → `false`; set it to `true` to keep the legacy `allOf` representation

# Changes in 7.1.4
- Added: `FluentValidationOperationTransformer` (`IOpenApiOperationTransformer`) for `MicroElements.AspNetCore.OpenApi.FluentValidation` (Issue #200)
 - Query parameters with `[AsParameters]` now receive validation constraints (min/max, required, pattern, etc.)
 - Supports container type resolution with fallback via reflection for `[AsParameters]`
 - Copies validation constraints from schema properties to parameter schemas
 - Registered automatically via `AddFluentValidationRules()`
- Fixed: Nested DTOs in request body not receiving validation constraints (Issue #200)
 - `FluentValidationSchemaTransformer` skipped all property-level schemas, but for nested object types this was the only transformer call
 - Now processes property-level schemas for complex types using the property type's validator

# Changes in 7.1.3
- Fixed: `$ref` replaced with inline schema copy when using `SetValidator` with nested object types (Issue #198)
 - `ResolveRefProperty` (introduced in 7.1.2 for BigInteger isolation) replaced all `$ref` properties with copies, destroying reference structure in the OpenAPI document
 - Fix: snapshot `$ref` properties before rule application, restore them afterwards if no validation constraints were added by rules
 - BigInteger per-model constraints (Issue #146) continue to work correctly

# Changes in 7.1.2
- Added: `BigInteger` support for min/max validation constraints in OpenAPI schema generation (Issue #146)
 - `IsNumeric()` and `NumericToDecimal()` now handle `BigInteger` values
 - `BigInteger` properties with GreaterThan, LessThan, InclusiveBetween, ExclusiveBetween rules produce correct `minimum`/`maximum` in Swagger
 - NSwag provider updated with the same `BigInteger` support
 - Out-of-range `BigInteger` values (exceeding `decimal` range) are handled gracefully via existing try/catch
- Fixed: Shared schema mutation when multiple models reference the same `BigInteger` type with different constraints (net10.0)
 - `ResolveRefProperty` creates an isolated shallow copy before applying rule mutations
 - Prevents `$ref`-based schema corruption across models in `SchemaRepository`
- Fixed: Replaced deprecated `PackageLicenseUrl` with `PackageLicenseExpression` (Issue #144)
- Fixed: Replaced deprecated `PackageIconUrl` with embedded `PackageIcon`


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