FluentValidation 8.0 is a major release that included several breaking changes. Please review this document before upgrading from FluentValidation 7.x to 8.
There have been several major underlying changes to the asynchronous validation workflow in FluentValidation 8. These should not have any impact to any existing asynchronous code other than that some methods now take a
CancellationToken when they didn’t before.
These changes were made to remove the internal dependency on the old Microsoft
TaskHelper classes and use
Instead of using
SetCollectionValidator you should use FluentValidation’s
RuleForEach support instead:
RuleFor(x => x.AddressLines).SetCollectionValidator(new AddressLineValidator());
RuleForEach(x => x.AddressLines).SetValidator(new AddressLineValidator());
SetCollectionValidator was added to FluentValidation in its initial versions to provide a way to use a child validator against each element in a collection.
RuleForEach was added later and provides a more comprehensive way of validating collections (as you can define in-line rules with RuleForEach too). It doesn’t make sense to provide 2 ways to do the same thing.
ErrorCodeSource are no longer directly exposed on
PropertyValidator, you should now access them via the
Options property on
It allows extra options/configuration to be added to property validators without introducing breaking changes to the interface going forward.
Use of the
ValidatorAttribute to wire up validators is no longer recommended and have been moved to a separate
FluentValidation.ValidatorAttributepackage will be automatically installed for compatibility. However, we recommend using an IoC container instead if you can.
You can now validate specific properties using a full path, eg:
validator.Validate(customer, "Address.Line1", "Address.Line2");
Previously, if you defined a child validator with
SetValidator, then whichever ruleset you invoked on the parent validator will cascade to the child validator. Now you can explicitly define which ruleset will run on the child:
RuleFor(x => x.Address).SetValidator(new AddressValidator(), "myRuleset");
FluentValidation 8 removes many old/deprecated methods that have been marked as obsolete for a long time.
RuleFor(x => x).Custom()instead. See the section on Custom Validators
WithLocalizedMessage. See the section on localization for more details.
ClearRulesmethods that have been marked obsolete for many years (FluentValidation does not offer a replacement for these as runtime modification of validation rules is not recommended or supported in any way)
CancellationToken(use the overloads that do accept them instead.)
IStringSource.GetString now receives a context, instead of a model. If you have custom
IStringSource implementations, you will need to update them.