aspnetcore: CompareAttribute not working properly with bound properties on the Razor Page's PageModel

I’m hitting this problem now too, with properties in my PageModel that are bound directly using [BindProperty].

I do not like the workaround of having to create a sub-model for the form since this means that the form field names are unnecessarily nested. An easier workaround would be to simply implement the comparison check in code then since that means that you wouldn’t have to update your model.

I do consider this a bug since all validation attributes do work except for [Compare]. Combined with the error which isn’t clear on this restriction at all, this makes this also very difficult to discover. I would assume that most people would just expect this to work out of the box.

Reopening as it seems there is enough involvement here to reconsider this.

In ASP.Net Core 2.2:

    public class RegisterModel : PageModel
	{
		public RegisterModel(UserManager<VocalsUser> userManager, ICaptchaService captchaService, IEmailSender emailSender)
		{
			UserManager = userManager;
			CaptchaService = captchaService;
			EmailSender = emailSender;
		}

		[Required]
		[BindProperty]
		[DataType(DataType.Text)]
		public string UserName { get; set; }

		[Required]
		[BindProperty]
		[DataType(DataType.EmailAddress)]
		public string Email { get; set; }

		[Required]
		[BindProperty]
		[DataType(DataType.Password)]
		public string Password { get; set; }

		[Required]
		[BindProperty]
		[DataType(DataType.Password)]
		[Compare(nameof(Password))]
		public string PasswordRepeated { get; set; }

CompareAttribute works nicely in view (i.e. with unobtrusive validation) but causes invalid ModelState to occur in the OnPost method. I’m effectively forced between doing either manual validation in the view without [Compare], or manually clearing the ModelState error in the OnPost method. That doesn’t sound right, especially when following Razor PageModel examples & tutorials like this one that list the [Compare] attribute as a viable validation technique for Razor pages.

I have also just encountered this problem. To me the workaround kind of defeats one the purposes of having the PageModel i.e It is the page’s model. I should not need a PageModel-model. Additionally, the other validators work. It is surprising to suddenly discover that Compare did not.

Just started out with Core and encountered this inexplicably dumb oversight. It makes absolutely no sense to respect some validation attributes and not others- especially IValidateableObject. In addition, I agree with others that the nested class solution is bonkers and defeats the purpose of PageModel.

Closing this issue as there was no community involvement for quite a while now.

Hi folks, we realize a lot of you are running in to this. Unfortunately the earliest we can do anything about this would be in the 5.0 milestone. In the meanwhile, a workaround is to use a wrapper type that contains properties with [CompareAttribute].

Was just bitten by this, adding my +1

Totally agree! On .NET Core using [Compare] MVC works, but not on Pagemodel! I had to change the code and implement IValidatableObject and validate it explicitly. Clumsy code 😦

Microsoft.AspNetCore.App 2.2.0 Bug is presented

I’d have to agree with @JohannSig. I shouldn’t need another model class inside my PageModel simply to use the [Compare] attribute functionality. One of the benefits of Razor Pages is combining the model and the controller for simple pages to reduce code size, but if I have to create another model for my PageModel to use, it negates this benefit and makes me wondering if I should just go back to MVC.

Unsure what being closed means here - will this ever be fixed?

@danroth27 @mkArtakMSFT @rynowak the new support for validation of top-level nodes does not pass the containing page model to ValidationAttributes, breaking [Compare] on page model properties. In addition, page model implementations of IValidatableObject are ignored. This is not what users should expect.

Though MVC passes an incorrectly-initialized ValidationContext for the page model property case, it’s difficult to call this a bug since a fix enables new scenarios. Suggest we treat this as an enhancement for a near-term release. One possibility would be to validate the page model itself, passing a custom IValidationStrategy to ignore properties that were not bound. (Could also add a ValidationVisitor.Validate(...) overload accepting the container object and use it for page model property validation. That would address @RKDMax’s scenario but not get page model IValidatableObject implementations working.)