Tips

Reusable Validation Error Message Resource Strings for DataAnnotations

Ryan Rivest — Sat, 16 Jan 2010 07:00:21 GMT

There are quite a few examples of using the attributes from System.ComponentModel.DataAnnotations out there in your ASP.NET MVC applications. If you haven’t been keeping up with what’s new in ASP.NET MVC 2, one of the biggest improvements is in the area of validation – which is now automatic if you decorate your models with the attributes. I recommend you check out ScottGu’s latest epic post on the topic to get up to speed.

Continuing with the Gu’s example, here is our Person class and the applied validation attributes:

    public class Person {
        [Required(ErrorMessage = "First Name is required.")]
        [StringLength(50, ErrorMessage = "First Name must be under 50 characters.")]
        public string FirstName { get; set; }

        [Required(ErrorMessage = "Last Name is required.")]
        [StringLength(50, ErrorMessage = "Last Name must be under 50 characters.")]
        public string LastName { get; set; }

        [Required(ErrorMessage = "Age is required.")]
        [Range(0, 120, ErrorMessage = "Age must be between 0 and 120.")]
        public int Age { get; set; }

        [Required(ErrorMessage = "Email is required.")]
        [Email(ErrorMessage = "You did not enter a valid email.")]
        public string Email { get; set; }
    }

This works great, but we can take it one step further and eliminate all the explicit error message strings by using a resource file. To add one, hit Ctrl+Shift+A to launch the Add New Item dialog. You can enter any name you like, I choose to keep it simple and named it Resources.

Next, we’ll add our error message strings to the resource file. Make note of the format items ({0}, {1}, etc.), as this is how the property names and validation attribute parameters are added to the error message. I’ll explain how this works later in this post. It’s also important to make sure the Access Modifier is set to Public. If it’s set to Internal, ASP.NET MVC 2’s DataAnnotations Model Binder won’t validate the property at all. This took me a few minutes to figure out what was happening, so don’t make the same mistake I did.

Now that we have our Resource file created and the validation error messages defined, we can change our Person class to make use of them. To get this working, all you need to do is specify the ErrorMessageResourceName and ErrorMessageResourceType when applying a validation attribute. Here’s our new Person class making use of the resources.

    public class Person {
        [Required(ErrorMessageResourceName = "Required_ValidationError", ErrorMessageResourceType = typeof(Resources))]
        [StringLength(50, ErrorMessageResourceName = "Required_ValidationError", ErrorMessageResourceType = typeof(Resources))]
        public string FirstName { get; set; }

        [Required(ErrorMessageResourceName = "Required_ValidationError", ErrorMessageResourceType = typeof(Resources))]
        [StringLength(50, ErrorMessageResourceName = "StringLength_ValidationError", ErrorMessageResourceType = typeof(Resources))]
        public string LastName { get; set; }

        [Required(ErrorMessageResourceName = "Required_ValidationError", ErrorMessageResourceType = typeof(Resources))]
        [Range(0, 120, ErrorMessageResourceName = "Range_ValidationError", ErrorMessageResourceType = typeof(Resources))]
        public int Age { get; set; }

        [Required(ErrorMessageResourceName = "Required_ValidationError", ErrorMessageResourceType = typeof(Resources))]
        [Email(ErrorMessageResourceName = "Email_ValidationError", ErrorMessageResourceType = typeof(Resources))]
        public string Email { get; set; }
    }

When we test the validation, we should see that the validation still works, and it’s now using our generalized error messages, substituting the property name and, if the validation attribute has any, the attribute parameters (as in the case of StringLength or the Range attributes).

It works great now, but that code still looks a little verbose to me. I don’t want to specify the resource string name and resource type every time I use one of the attributes. My preferred approach is to subclass the validation attributes with my own of the same name. Let’s do that now. The strategy here is to pass the heavy lifting off to the original attribute’s constructor (if necessary), and initialize the 2 properties that we were hard-coding before.

    public class RequiredAttribute : System.ComponentModel.DataAnnotations.RequiredAttribute {
        public RequiredAttribute() {
            ErrorMessageResourceName = "Required_ValidationError";
            ErrorMessageResourceType = typeof (Resources);
        }
    }

    public class StringLengthAttribute : System.ComponentModel.DataAnnotations.StringLengthAttribute {
        public StringLengthAttribute(int maximumLength) : base(maximumLength) {
            ErrorMessageResourceName = "StringLength_ValidationError";
            ErrorMessageResourceType = typeof (Resources);
        }
    }

    public class RangeAttribute : System.ComponentModel.DataAnnotations.RangeAttribute {
        public RangeAttribute(int minimum, int maximum) : base(minimum, maximum) {
            InitializeErrorMessageResource();
        }

        public RangeAttribute(double minimum, double maximum) : base(minimum, maximum) {
            InitializeErrorMessageResource();
        }

        public RangeAttribute(Type type, string minimum, string maximum) : base(type, minimum, maximum) {
            InitializeErrorMessageResource();
        }

        private void InitializeErrorMessageResource() {
            ErrorMessageResourceName = "Range_ValidationError";
            ErrorMessageResourceType = typeof(Resources);
        }
    }

    public class EmailAttribute : RegularExpressionAttribute {
        public EmailAttribute() : base("^[a-z0-9_\\+-]+(\\.[a-z0-9_\\+-]+)*@[a-z0-9-]+(\\.[a-z0-9-]+)*\\.([a-z]{2,4})$") {
            ErrorMessageResourceName = "Email_ValidationError";
            ErrorMessageResourceType = typeof (Resources);
        }
    }

This really cleans up our model class, which now looks like this:

    public class Person {
        [Required]
        [StringLength(50)]
        public string FirstName { get; set; }

        [Required]
        [StringLength(50)]
        public string LastName { get; set; }

        [Required]
        [Range(0, 120)]
        public int Age { get; set; }

        [Required]
        [Email]
        public string Email { get; set; }
    }

Much better, and our validation still works as we expected, without all the string and type duplication. The only problem I see now is that our error messages use the exact property name, which isn’t always what we want. For example, when the user submits the form without entering a value in the FirstName field, they receive the error message “FirstName is required.” I would much rather see “First Name is required.” instead. Good news! They made this really easy to change for nitpickers like me.

To get our property name showing up nicely, all we have to do is apply the DisplayName attribute to the FirstName property.

    [DisplayName("First Name")]
    public string FirstName { get; set; }

This also has the added benefit of updating the FirstName field’s label as well, since we’re using ASP.NET MVC 2’s strongly typed label HTML helper (which uses the property name if no display name is available).

As a bonus, if we enable client side validation, everything still works! You can see an example of this in the sample code (link below).

How it Works: FormatErrorMessage()

Let’s take a peek inside the FormatErrorMessage() method on the StringLengthAttribute:

public override string FormatErrorMessage(string name) {
    return string.Format(CultureInfo.CurrentCulture, base.ErrorMessageString, new object[] { name, this.MaximumLength });
}

Every ValidationAttribute will either inherit this method, or implement their own (if it has additional parameters, like String Length, which has a maximum length that is supplied to the attribute. As you can see, this method is simply using string.Format, and supplying the name as {0} and the MaximumLength property as {1}. Simple enough, right?

If you want to poke around in the code, you can download the sample here.

Getting Windows Installer Projects to Upgrade Previous Versions

Ryan Rivest — Sat, 12 Sep 2009 08:35:11 GMT

This tip applies to Visual Studio 2008 and Windows Installer (Setup) Projects. They’re used to create *.msi installers for deploying applications.

I was having some weird issues with my setup project. When I tested the installer against the previous version of the installer, it would run fine without reporting any errors, but when I launched my application, the changes I made weren’t showing up.

Odd, I thought. I figured the installer wasn’t working properly. What I was expecting was an uninstall to show up before the install ran. This is actually the behavior in Visual Studio 2005 setup projects. It’s different in Visual Studio 2008.

Problem

I incremented my setup project’s Version from 1.0.0 to 1.0.1, thinking this was good enough for the installer to upgrade a previous installer and grab the new application files.

If you investigate further, it will become apparent that the installer did indeed run. You’ll also discover that none of the application’s assemblies or other files have been updated after running the installer.

As I briefly alluded to above, you apparently wouldn’t have this problem in Visual Studio 2005 due to the behavior of the legacy installers. They actually do run an uninstall on the old installer, and install the new version. Visual Studio 2008 behaves differently.

Solution

There are two important steps to get the installer upgrades working properly in Visual Studio 2008.

Increment the Deployment Project's Version
For example, if your current version is 1.0.0, change it to 1.0.1
Increment the file versions
[assembly: AssemblyVersion("1.0.0.1")] [assembly: AssemblyFileVersion("1.0.0.1")]

In Visual Studio 2008, a file version comparison occurs when the new installer runs against an older installer, replacing anything that has changed rather than running an uninstall/reinstall. Overall it’s much nicer for upgrades, but confusing if you don’t know what’s happening and forget to change the file versions like I did.

General Rules About Installer Upgrades in Visual Studio 2008

Old and new products must have identical UpgradeCode values and different ProductCode values.
Old and new products must have identical values for InstallAllUsers.
New product's setup Version (the setup project, nothing to do with file versions) must be higher.
All setup versions (again, not file versions) must be 1.0 or greater.
Visual Studio 2008 RemovePreviousVersions is not the same as 2005 and uses file update rules. Therefore if you want to update files you must increase file versions. This is normal practice in all setups, patches, etc. that file versions are updated if they have new content.
Visual Studio 2005 RemovePreviousVersions behaves like an uninstall of the older one, followed by an install of the new one, and rules 1-4 still need following, but you could get away with not incrementing changed file versions because of the "uninstall, then install" nature of the upgrade.

Thanks go out to Phil Wilson for the information!

Hope this helps someone else

Tip: Returning Multiple Mocks with the Same Method

Ryan Rivest — Sat, 11 Jul 2009 07:13:18 GMT

Being fairly new to unit testing, I find myself discovering all kinds of interesting challenges when trying to test my data access layer (DAL). I had decided early on in one of my projects (with the tutelage of my supervisor and mentor) to take on the task of writing my DAL from scratch.

Disclaimer: I realize that data access is a problem that has already been solved (many times over), this was more of a learning exercise for me.

Part of my DAL deals with the IDbCommand.CreateParameter() method. I ran into a problem where I wanted each subsequent call of CreateParameter() to return a different mock IDbDataParameter. After some brief searching, I ran into a thread on Moq Discussions from someone with the same problem, and a very elegant solution.

var parameters = new Queue<IDbDataParameter>(new[] { mockFirstParam.Object, mockSecondParam.Object }); 

mockCommand.Expect(c => c.CreateParameter()).Returns(() => pq.Dequeue());

First we set up a generic Queue of IDbDataParameters, initialized with an array of mock IDbDataParameter objects that have already been created.

Then we set the behavior of our mock IDbCommand’s CreateParameter() method to the queue's Dequeue() method so that each subsequent call will return the next mock in the queue.

We use TypeMock Isolator in our shop, so here's the same code using TypeMock Isolator's AAA syntax:

var parameters = new Queue<IDbDataParameter>(new[] { mockFirstParam, mockSecondParam });

Isolate.WhenCalled(() => command.CreateParameter()).DoInstead(param => parameters.Dequeue());

This code behaves the same as its Moq counterpart, the only difference is how we use the API.

Hope someone else finds this useful. Thanks to the original author!