CompareAttribute.Validate method does not create a ValidationResult with MemberNames

[ChrisJWoodcock]

When the CompareAttribute creates its ValidationResult it does not include the MemberNames of the context - I believe when this is used from Model Binding the actual property name which is the MemberName is added later, so the CompareAttribute can be used to correctly populate an error on a View (I can't locate where this correction occurs in the source); in the ValidationAttribute the MemberNames are used correctly.

This is preventing me from writing a unit test that checks that a Compare is made between two properties by specifying the property name exactly.

---

@pranavkm:

Blazor relies on this attribute and ran in to this issue. Our workaround was to produce an alternate attribute that passed the member in. Given the reluctance to change behavior in this area of the code, my proposal is to move the attribute to the runtime that has the behavior

API:

The new API is a clone of CompareAttribute with the "fixed" behavior:

   [System.AttributeUsageAttribute(System.AttributeTargets.Property, AllowMultiple=false)]
    public partial class ComparePropertyAttribute : System.ComponentModel.DataAnnotations.ValidationAttribute
    {
        public ComparePropertyAttribute(string otherProperty) { }
        public string OtherProperty { get { throw null; } }
        public string OtherPropertyDisplayName { get { throw null; } }
        public override bool RequiresValidationContext { get { throw null; } }
        public override string FormatErrorMessage(string name) { throw null; }
        protected override System.ComponentModel.DataAnnotations.ValidationResult IsValid(object value, System.ComponentModel.DataAnnotations.ValidationContext validationContext) { throw null; }
    }

Alternatives proposals

• Fix the implementation. The behavior isn't documented so it might be safe to change this. However, the library targets ns2.1 (used outside .net core), has been stable for ages, isn't very actively maintained and the owner doesn't want to incur any additional support costs.
• Add a property that opts CompareAttribute to use the updated implementation. Nothing against this, I just personally prefer creating a new attribute to adding switches to smooth over implementation detals.

[terrajobst]

Tagging area owners @lajones @ajcvickers