DependentRules when using .Custom() validation

[mythjuha]

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

I'm using Custom validation to compare a few sets of timeranges and want to return a detailed error message to the user so he knows which timeranges are causing problems. As the timeranges are based on calculations it's not ideal to split these up into seperate validators because then the calculations would need to be repeated every time. Hence the custom validation with .addFailure() messages works best.

Only if those validations succeed, do I want to continue checking a set of other rules. Checking these rules if the previous set fails would only cause confusion in the error list. For this this library has the .DependentRules option, but this option is not available when calling a .Custom() validation.

Describe the solution you'd like

this.RuleFor(o => o).Custom(CustomValidationMethod)
.DependentRules(() => 
{
  this.RuleFor(~~~~~~~~);
});

Describe alternatives you've considered

Also found documentation on using the When() syntax, but can't seem to get this to work either. I suppose I could add the dependentrules check at the end of the custom validator, but that would result into less readable code.

Additional Context

No response

[mythjuha]

Currently 'resolved' the issue by abusing the RootContextData. I add a key/value to it whenever i call 'AddFailure'. It would've been nice if we could just access the Failures property of the context.

When((o, context) =>
{
   CustomValidatorMethod(o, context);
   return !context.RootContextData.ContainsKey("HasFailures");
}, () =>
{
   this.RuleFor(~~~~~~~~);
});

[JeremySkinner]

Thanks for the suggestion - we can look at that in the future. For now, you can achieve the same result by using Must instead of Custom - Must can still call AddFailure internally, but just return true from the callback so it doesn't auto-generate a failure, and then chain on a condition as usual.

[JeremySkinner]

Added in 3775c94. Will be part of the 11.9 release.

[JeremySkinner]

I had to revert this as it requires a breaking change, so isn't something that can be implemented in 11.x. Will re-target for 12.0 instead.

[JeremySkinner]

Implemented in #2177, for 12.0