Request for feedback: The future of our ASP.NET Integration package

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?

[JeremySkinner]

Thanks everyone for your input so far, I really appreciate it and it’s really encouraging.

I took some time to think think about this further over the weekend and based on the feedback received so far have decided on the following for now:

• I will immediately deprecate the features in FluentValidation.AspNetCore that are most problematic (mainly those related to implicit child validation)
  • I will aim to put together some instructions for how to bring this functionality into your own codebase for anyone who relies on this functionality.
• I’ll also deprecate several features which are duplicated elsewhere (see #1963, #1961, #1965)
• I have reworked the ASP.NET documentation to make it clear that manual validation is the preferred approach, and discourage the use of auto-validation
• The AddFluentValidation() method will be replaced with 2 methods: AddFluentValidationAutoValidation() and AddFluentValidationClientsideAdapters() to make it easier for users to enable the clientside validation integration without enabling auto validation (#1965)
  • I might move the clientside integration to a separate package. Not sure yet.
• I will keep an eye on this issue to see whether Microsoft reconsider enabling asynchronous validation for .net 8. If they do, then I may keep auto-validation around (albeit in a more limited form).

That’s my current plan, although I may change things depending on how the first set of deprecations are received by the wider community. I’ll aim to post any further updates here too.

I’ve relased 11.1.0 with these changes.

Please check out the updated docs and let me know if there’s anything that doesn’t make sense that could do with clarifying/expanding.

[smartprogrammer93]

I suggest going with option 2. I dont see why the community cant pick up the maintainance, as well as having and explaining in the docs the manual validation approuch and introducing the helper that maps to ModelState. Appreciate your efforts on this lib. It is amazing