Die .NET-Klasse System.ComponentModel.DataAnnotations.ValidationContext verwendet bisher sogenannte „Unbound Reflection“ (Reflection auf einem Typ, der zur Compile-Zeit nicht bekannt ist), um bei dem zu validierenden Objekt die Annotation [DisplayName] zu suchen.

Das funktioniert aber nicht mit dem NativeAOT-Compiler.

Bisher erschien eine Warnung beim Einsatz von ValidationContext bei Native AOT-Kompilierung (Abb. 1).

Eine neue Überladung löst das Problem: Man kann nun den Displayname als Parameter beim Konstruktor angeben:

var context = new ValidationContext(person, "PersonObjekt", null, null);

Folgendes Codebeispiel zeigt den Einsatz von ValidationContext:

using System.ComponentModel.DataAnnotations;
using ITVisions;
 
namespace NET10_Console;
internal class FCL10_ValidationContext
{
 [Display(Name = "Personobjekt")]
 public class Person
 {
  [Range(1, Int32.MaxValue)]
  [Display(Name = "Person-ID")]
  public int ID { get; set; }
 
  [Required]
  [Display(Name = "Person-Name")]
  public string Name { get; set; }
 
  [Range(0, 120)]
  [Display(Name = "Person-Age")]
  public int Age { get; set; }
 }
 
 public void Run()
 {
  CUI.Demo(nameof(FCL10_ValidationContext));
 
  var person = new Person { ID = 0, Name = "", Age = 150 }; // absichtlich ungültig
 
  //var context = new ValidationContext(person); // Dieser Konstruktor wird via Reflection [Display] suchen
  var context = new ValidationContext(person, "Person-Objekt", null, null); // Dieser neue Konstruktor funktioniert auch mit AOT
  var results = new List<ValidationResult>();
 
  bool isValid = Validator.TryValidateObject(person, context, results, validateAllProperties: true);
 
  if (!isValid)
  {
   CUI.LineRed("Validierungsfehler bei " + context.DisplayName + "");
   foreach (var validationResult in results)
   {
    CUI.LI(validationResult.ErrorMessage);
   }
  }
  else
  {
   CUI.Success($"{context.DisplayName} ist gültig.");
  }
 }
}

Ausgabe des Codebeispiels (Abb. 2)

(rme)