FluentValidation 9.0 - list of breaking changes

This is a working list of the expected breaking changes in 9.0:

• Generic type parameters added to a couple of places (ChildValidatorAdaptor, IncludeRule)
• Remove support for netstandard1.1 and netstandard1.6
• Instead of net45 will support net461 as the new minimum
• Drop support for MVC5 and WebApi 2. These will continue to receive critical fixes for 8.x only.
• Remove SetCollectionValidator, which was deprecated with 8.0 (RuleForEach is the alternative)
• Remove ReplacePlaceholderWithValue and GetPlaceholder from MessageFormatter
• Remove WithLocalizedMessage and LocalizedStringSource. Using the overload of WithMessage that takes a func can cover the use case of needing to work with strongly-typed resource wrappers.
• ResourceName and ResourceType will be removed from IStringSource.
• ResourceName removed from ValidationFailure.
• Removed PropertyValidatorContext.Instance - use PropertyValidatorContext.InstanceToValidate instead.
• DelegatingValidator removed.
• Email validation mode: defualt changed from regex, to asp.net core compatible.
• Syntax changes for advanced test helper (#1148)
• Severity changes (#1152)
• ComparisonProperty formatting (#1204)
• Rename ShouldValidateAsync (#1279)
• Equal/Notequal now do ordinal comparisons for strings (#1301)
• Do not attempt to automatically infer property names from the presence of DisplayNameAttribute or DisplayAttribute, as this no longer works properly with the way asp.net core handles localization. If you really want this behaviour back, add the following to startup:

ValidatorOptions.DisplayNameResolver = (type, memberInfo, expression) => {
	return memberInfo.GetCustomAttribute<System.ComponentModel.DataAnnotations.DisplayAttribute>()?.GetName();
};

[JeremySkinner]

@cjlotz so you’ll need to change your implementating to not be based on the DelegatingValidator, and instead switch to using FluentValidation’s condition API, which is done by passing a Func<PropertyValidatorContext, bool> to ApplyConditon that does the work that you’d previously be doing inside the DelegatingValidator.

// Step 1: WhenExpr. This can now simply define a Func<PropertyValidatorContext, bool> that evaluatuates your CriteriaExpression, and then pass the func directly to FluentValidation's propertyRule.ApplyCondition method. Your ApplyCondition method can be removed completely.

public static IRuleBuilderOptions<T, TProperty> WhenExpr<T, TProperty>(this IRuleBuilderOptions<T, TProperty> rule, CriteriaExpression predicate, ApplyConditionTo applyConditionTo = ApplyConditionTo.AllValidators) {
	var predicateFunc = new Func<PropertyValidatorContext, bool>(ctx => {
		if (predicate.ShouldExecute(ctx))
			return predicate.Evaluate(ctx.InstanceToValidate);

		return false;
	});

	return rule.Configure(propertyRule => propertyRule.ApplyCondition(predicateFunc, applyConditionTo));
}

// Step 2, your WhenInOperation/WhenNotInOperation methods can be implemented in a similar way by defining a function that does the work, which you then pass to ApplyCondition:
public static IRuleBuilderOptions<T, TProperty> WhenInOperation<T, TProperty>(this IRuleBuilderOptions<T, TProperty> rule, params IOperationStep[] steps) {
	var predicateFunc = new Func<PropertyValidatorContext, bool>(ctx => {
		IOperationContext context = ctx.ParentContext.GetOperationContext();
		return context.InOneOfOperations(steps);
	});

	return rule.Configure(propertyRule => propertyRule.ApplyCondition(predicateFunc));
}

Hopefully that illustrates what you’ll need to do to port to 9.0. Note that FluentValidation 8.x switched internally from using DelegatingValidator to the conditon API a while back, so you can switch over to this today without needing to wait for 9.0.

Of course, the other option is that you could copy the DelegatingValidator from the 8.x source code into your own project if you want to keep using it (source), but I would highly recommend moving over to the condition API instead.

If you have any further questions, could you open a separate issue? Thanks.

[cjlotz]

Other areas where we use the flexibility afforded by DelegatingValidator is also to specify when specific rules should/should not execute based on the current stack of requests (we call them IOperationSteps) for the current request/operation being executed in the system.

    public class InOperationValidator : DelegatingValidator
    {
        private readonly IOperationStep[] _steps;
        
        public InOperationValidator(IOperationStep[] steps, IPropertyValidator innerValidator)
            : base(ctx =>
            {
                IOperationContext context = ctx.ParentContext.GetOperationContext();
                return context.InOneOfOperations(steps);
            }, innerValidator)
        {
            _steps = steps;
        }
        public IEnumerable<IOperationStep> Steps => _steps;
    }

This allows us to specify rules like the following:

RuleFor(x => x.Id).GreaterThanOrEqualTo(0).WhenNotInOperation(SyncOperations.SaveSyncContainer)