I am considering the future of our FluentValidation.AspNetCore package:

Background

We ship the FluentValidation.AspNetCore alongside our core FluentValidation package in order to provide integration with ASP.NET Core in 2 main ways:

• Integration with ASP.NET Core's auto-validation pipeline
  • When ASP.NET attempts to validate an object during model-binding, FluentValidation can be invoked to handle this process.
• Integration with ASP.NET Core's client-side validation process
  • We provide adaptors that convert a limited subset of FluentValidation's rules into html attributes that can be used with jQuery Validation.

The problem

The FluentValidation.AspNetCore package is problematic to maintain for several reasons:

Async Validation:
ASP.NET's validation pipeline is synchronous*, meaning none of FluentValidation's support async rules can be utilised and Microsoft do not seem keen on providing asynchronous validation apis in ASP.NET (although they are reconsidering this for .net 8). As asynchronous code becomes more and more prevalent, the sync-only approach taken by asp.net core is particularly limiting and feels extremely antiquated.

• Note that this only applies to MVC/Web APIs. Blazor's validation process is asynchronous, and Minimal APIs don't provide any kind of auto-validation (you invoke the validator manually, and act upon its results, which is actually my preferred approach).

Maintenance burden
The ASP.NET validation pipeline has contained breaking changes for almost every release of ASP.NET Core (.net 7 is the first where nothing has broken during the upgrade). Some of these have required a significant time investment to track down and troubleshoot, especially as the ASP.NET validation pipeline is quite complex internally. This isn't an enjoyable experience for me and I'm not keen on continuing to have to do this with every release.

Support burden
The ASP.NET validation pipeline is complex and often hard to understand, largely because of the 'magic' nature of auto-validation and the vast majority of support requests I receive on this issue tracker are related to this. Even though there usually isn't an issue with FluentValidation itself it's hard for developers to understand when an issue lies with ASP.NET (most of the time), vs when it lies with FluentValidation (rarely).

The support burden for FluentValidation.AspNetCore is extremely frustrating for me to the point where I wish I'd never built and supported this myself, and instead focused only on the core FluentValidation library and allowed the community to maintain the ASP.NET integration separately. (Like we do for Blazor)

The majority of issues I've had in my personal life related to "OSS-burnout" is largely due to FluentValidation.AspNetCore.

The future

Essentially: I don't really want to support FluentValidation.AspNetCore anymore and I'd like the community's input on what to do with it going forward (and to clarify; I do still want to support the main FluentValidation library!)

Option 1: Deprecate the package and provide guidance for alternative approaches

• Encourage users to manually invoke validators rather than rely on auto-validation
• We might have to provide some better helpers for copying validation results into ModelState
• FluentValidation.AspNetCore would be deprecated and receive no further updates or support from me
  • Users could continue to use it if they wanted, unsupported (until some future ASP.NET update breaks it)

Option 2: The community takes over maintaining it
If anyone in the community is willing to put the time investment into maintaining and supporting FluentValidation.AspNetCore then this would be an alternative option:

• The code for FluentValidation.AspNetCore is moved into a new repository, maintained by the community and publishes it as a new package
  • We wouldn't transfer ownership of the existing package due to chain-of-trust issues. Instead the existing package would be deprecated and the new community package would be recommended a a replacement
• In our own documentation we would encourage users to manually invoke validators rather than rely on auto-validation, but also link to the community package as an alternative

Option 3: Maybe some kind of commercial approach

• Maybe move to a paid license, or try and find corporate sponsors willing to pay for ongoing maintenance for the library.
• This doesn't seem realistic

What do you all think?