Support internal request DTOs in built-in Minimal API validation

[BrunoBeraud]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

Hello,
With the introduction of built-in request DTO validation for Minimal APIs in ASP.NET Core 10, developers can benefit from automatic validation of request models registered via the new validation infrastructure.

However, the current implementation does not take internal request DTOs into account when discovering and applying validators.

This creates a limitation in scenarios where:

• DTOs are intentionally marked as internal to preserve encapsulation within an assembly.
• Applications follow clean architecture or modular monolith patterns.
• Feature-based folder structures group endpoints and DTOs inside the same assembly but avoid exposing types publicly.

At the moment, only public DTOs appear to be discovered and validated automatically. As a result, internal request models are silently ignored by the validation pipeline.

Describe the solution you'd like

Introduce support for discovering and validating internal request DTOs.

This could be implemented similarly to how FluentValidation handles internal types — by allowing an opt-in configuration flag when registering validation services.

For example:

builder.Services.AddValidation(options =>
{
    options.IncludeInternalTypes = true;
});

Or alternatively:

builder.Services.AddValidation(includeInternalTypes: true);

Key aspects of the proposal:

• Default behavior remains unchanged (public types only).
• Opt-in flag enables scanning and validation of internal DTOs.
• Maintains backward compatibility.
• Gives developers control over assembly scanning behavior.

Additional context

• Internal DTOs are common in modern .NET architectures where APIs are not intended to expose request/response contracts outside the assembly boundary.
• Current behavior may lead to confusion because validation silently does not apply.
• This enhancement would improve consistency with existing validation ecosystems and align with common encapsulation practices in .NET.

This feature would make the new Minimal API validation system more flexible while preserving its simplicity and performance characteristics.

Thank