runtime: [Extensions.Options] ValidateDataAnnotation doesn't work when classes have properties that also have DataAnnotations on their members

I know that it’s possible to fix, but this should be part of the .NET runtime. Not an extension method I need to copy to every application I ever work on.

It seems like this will be fixed in .NET 8 with the new attribute ValidateObjectMembersAttribute, see #90275

Just came across this issue and am quite flabberghasted and annoyed that recursive validation does not take place nor is there an option to set it. It has cost me a decent chunk of time trying to figure out why my tests were failing.

I echo the request to at least document this to save others frustration time.

Another question would be why this was removed from the 6.0.0 milestone. Are inclusions in these milestones not commitments but “best effort” ?

@maryamariyan It feels very weird to me to include https://github.com/dotnet/runtime/issues/36391 in release 6 but not this issue. I guess it’s too late now though. An idea is to at least add to the documentation for Options Validation that it (currently) only validates fields on the top Options class, not fields in nested Options classes.

It would be good to address this in 7.0.

Found a workaround for nested objects based on similar StackOveflow question and corresponding Nuget package. It works for nested objects, arrays and dictionaries but requires some preparation:

• Installing the package: Install-Package DataAnnotationsValidator or copying the code from the repository
• Creating custom options validator:

public class RecursiveDataAnnotationValidateOptions<TOptions>: IValidateOptions<TOptions> where TOptions: class
{
    private readonly DataAnnotationsValidator.DataAnnotationsValidator _validator = new();

    public RecursiveDataAnnotationValidateOptions(string name) => Name = name;

    public string Name { get; }

    public ValidateOptionsResult Validate(string name, TOptions options)
    {
        if (name != Name)
            return ValidateOptionsResult.Skip;

        var results = new List<ValidationResult>();
        if (_validator.TryValidateObjectRecursive(options, results))
            return ValidateOptionsResult.Success;

        var stringResult = results.Select(validationResult =>
            $"DataAnnotation validation failed for members: '{string.Join((string?)",", (IEnumerable<string?>)validationResult.MemberNames)}' with the error: '{validationResult.ErrorMessage}'."
        ).ToList();

        return ValidateOptionsResult.Fail(stringResult);
    }
}

• Creating extension method for it:

public static OptionsBuilder<T> ValidateDataAnnotationsRecursively<T>(this OptionsBuilder<T> builder) where T: class
{
    builder.Services.AddSingleton<IValidateOptions<T>>(new RecursiveDataAnnotationValidateOptions<T>(builder.Name));
    return builder;
}

Usage should be simple - just replace calls of ValidateDataAnnotations with ValidateDataAnnotationsRecursively.

Hey, any news with solution for that issue?

For Options validation, you can use this NuGet package (source and docs (GitHub)) until the release of .NET 7 (or 8, 9…).

It is compatible with .NET Standard 2.0, .NET Core 3.1, .NET 5 and .NET 6.

It provides two OptionBuilder extension methods:

• ValidateDataAnnotationsRecursively: based on Microsoft.Extensions.Options.DataAnnotations, but it can even validate nested properties
• ValidateOnStart: call Microsoft.Extensions.Hosting method in version 6, but custom code in previous .NET version

And a ServiceCollection extension method:

services.ConfigureAndValidate<TOptions>(configureOptions)

which is syntactic sugar for

services
    .AddOptions<TOptions>()
        .Configure(configureOptions) // Microsoft
        .ValidateDataAnnotationsRecursively() // based on Microsoft's ValidateDataAnnotations, but supports nested properties
        .ValidateOnStart() // Microsoft (.NET 6) or ValidateEagerly() in previous versions
        .Services

https://github.com/dotnet/runtime/issues/85475 is adding a ValidateObjectMembersAttribute which would handle this case. There is a question about whether that attribute should live in System.ComponentModel.DataAnnotations or in Microsoft.Extensions.Options.

cc @jeffhandley @DamianEdwards @tarekgh

I’m still interested in having this issue addressed.

I also came across this issue and would like to have seen at least a large disclaimer that this does not work as one would reasonably expect from a released (finished?) product. I agree with https://github.com/dotnet/runtime/issues/36093#issuecomment-755586930

I came up with my own workaround, where the only requirement is that all option types are defined in the same namespace. It’s tuned to my specific needs, but maybe it is useful to someone. 🙂

(The namespace requirement is just one way to prioritize specificity over sensitivity - matching e.g. a string is evidently wrong and will even result in a runtime exception. Finer tuned approaches could check for the presence of annotations on the members, for example.)

public static class ServiceConfiguration
{
  private static readonly MethodInfo HelperMethod =
    typeof(ServiceConfiguration).GetMethod(nameof(AddValidatedOptions), BindingFlags.Static | BindingFlags.NonPublic)
    ?? throw new InvalidOperationException("famously, this should not happen");

  public static IServiceCollection AddValidatedOptions<TOptions>(this IServiceCollection services, string sectionPath)
    where TOptions : class
  {
    var @namespace = typeof(TOptions).Namespace
                     ?? throw new ArgumentException("could not get namespace of type", nameof(TOptions));
    AddValidatedOptions<TOptions>(services, sectionPath, @namespace);
    return services;
  }

  private static void AddValidatedOptions<TOptions>(IServiceCollection services, string sectionPath, string @namespace)
    where TOptions : class
  {
    services
      .AddOptions<TOptions>()
      .BindConfiguration(sectionPath)
      .ValidateDataAnnotations()
      .ValidateOnStart();

    foreach (var pi in typeof(TOptions).GetProperties(BindingFlags.Instance | BindingFlags.Public))
    {
      bool skip = !pi.PropertyType.IsClass
                  || string.CompareOrdinal(pi.PropertyType.Namespace, @namespace) != 0;
      if (skip)
      {
        continue;
      }

      string currentPath = string.Join(':', sectionPath, pi.Name);
      HelperMethod.MakeGenericMethod(pi.PropertyType)
        .Invoke(null, new object[] { services, currentPath, @namespace });
    }
  }
}

Use as follows:

services.AddValidatedOptions<ComplexOption>("path:to:complex:option:that:is:probably:way:shorter:than:this:example");

Lastly, this is a recursive implementation, so don’t go and use this with configuration files that nest … a lot of objects. (What kind of monster would do that?)

I know that it’s possible to fix, but this should be part of the .NET runtime. Not an extension method I need to copy to every application I ever work on.

Options is part of every applications. Some may have lots of. Nesting options is obvious in this case as it helps sorting them. It is even the purpose of the Option pattern. And adding lots of options in the DI to avoid nesting them is not a good idea because you may have a service using many of them and this will result in a method declaration with lots of parameters for each options you need instead having only one option “registry” you can navigate into.