MrKWatkins

A Data Annotations Aware Model Binder

The System.ComponentModel.DataAnnotations assembly added with .NET 3.5 SP1 is quite useful. It contains various attributes that allow you to specify various constraints on the properties of your class. Ideal for model classes; constraints on the data are kept inside your model, nice and succinctly. However ASP.NET MVC version 1 does not contain out of the box server side support for them. Version 2 will but I can't wait that long... Whilst you can use something like the excellent xVal for client side validation of data annotations being a good programmer you'll also want to have the same validation server side in case someone turns off JavaScript in their browser.

Sadly I haven't been able to find a good example of how to do this. The examples I have found tend to require manual calls to some method to perform the validation, such as this one in Steve Sanderson's blog about how to use xVal. I don't want to have to do an extra manual call for my validation; I might forget! The ideal would be a model binder that is aware of the data annotations; I could set it as the default binder and forget about it. The only example of a model binder I could find was in the ASP.NET site on CodePlex but that required a newer version of the DataAnnotations assembly (basically the .NET 4.0 one) which seemed like overkill to me. How hard can it be to write one?

Turns out not very... All you have to do is:

1. Create a class that inherits from DefaultModelBinder.
2. Override the OnPropertyValidating method. Your version should call the base method to get the errors from the default binder then look for any ValidationAttributes on the property, check if there are errors by calling the IsValid method and add them to the ModelState if there are. Something like this:
   

   protected override bool OnPropertyValidating(ControllerContext controllerContext, ModelBindingContext bindingContext, PropertyDescriptor propertyDescriptor, object value)
   {
   	// Run everything by the default implementation first before checking data annotations.
   	var isValid = base.OnPropertyValidating(controllerContext, bindingContext, propertyDescriptor, value);
   	
   	// Loop through any validation attributes.
   	foreach (var validationAttribute in propertyDescriptor.Attributes.OfType<ValidationAttribute>())
   	{
   		// Are we valid?
   		if (!validationAttribute.IsValid(value))
   		{
   			// No. Let's add the error to the model state and set our isValid status to false.
   			string key = CreateSubPropertyName(bindingContext.ModelName, propertyDescriptor.Name);
   			
   			// Add the error to the model state.
   			bindingContext.ModelState.AddModelError(key, validationAttribute.FormatErrorMessage(propertyDescriptor.DisplayName)));
   			isValid = false;
   		}
   	}
   	return isValid;
   }

3. Replace the default model binder with an instance of your new one via the ModelBinders.Binders.DefaultBinder property.

Okay, it's not quite as simple as that. You also have to take into account any MetadataTypeAttributes that might be found on your model class. This attribute allows you to specify another type to put your metadata on. You can specify identical properties on this other type and decorate them with the DataAnnotations attributes instead. Pointless? Well yes, it should be really; why not just decorate your properties? However it comes in useful if you're working with auto-generated code that doesn't allow you to add attributes, such as the evil and crappy LINQ to SQL designer. By using the MetadataTypeAttribute you can create a partial version of your LINQ to SQL entity class, add the attribute to that and specify constraints for the auto generated properties in some other class. (Whether you should be using LINQ to SQL entities as your model is an ethical debate I am going nowhere near)

If you can't be bothered to do all this of course then please feel free to download one I made earlier. This binder takes into account MetadataTypeAttributes and I've even thrown in a demo project so you can see the thing in action. Enjoy!

Valid XHTML In Redirects

I've been using the Search Engine Optimization Toolkit add-in for IIS 7 to analyse this website. If you've not used it before I recommend you give it a try; it's very good for picking up random bugs, spurious URL routing and dodgy links that you'd never have spotted otherwise. For example it would report issues on this site whereby the same content was accessible by two different URLs. Turns out some links would have a trailing slash, some not. (Mainly due to ASP.NET MVC's ActionLink being rubbish and missing off trailing slashes. Why does it not return links in the format specified by the route???) The SEO toolkit picked them up and now they're hopefully all fixed.

One set of problems I had trouble fixing was the root URL to this site, http://www.mrkwatkins.co.uk/. Currently I only have a blog so that URL redirects to the root URL of my blog, http://www.mrkwatkins.co.uk/Blog/. However the SEO Toolkit would report errors with the content returned from the redirect. For example it would tell me that there was no <h1> tag in the content. Now whether or not the toolkit should be analysing the content returned from a redirect or not I have no idea. What I do know is that they were the last errors on my report and needed removing!

The redirect was done using the standard RedirectResult in ASP.NET MVC. This in turn uses the standard Response.Redirect from ASP.NET. Trouble is that Response.Redirect spits out the following content as well as the 302 status code and location HTTP header:

<html><head><title>Object moved</title></head><body>
<h2>Object moved to <a href="http://www.mrkwatkins.co.uk/Blog/">here</a>.</h2>
</body></html>

So to fix the problems we need to change this XHTML. Turns out that is pretty simple to do. You can return whatever content you like from the request as normal. All you need to do is set the status code to 302 using the Response.StatusCode property and set the Location HTTP header using the Response.RedirectLocation property. I've wrapped all this up in a custom ViewResult class:

using System.Web;
using System.Web.Mvc;
using KWatkins.Validation;

namespace KWatkins.MrKWatkins.Web.Mvc
{
    /// <summary>
    /// A <see cref="ViewResult" /> that redirects the user to another location; allows
    /// you to customize the XHTML returned by the redirection rather than use the
    /// standard (invalid XHTML) retured by <see cref="HttpResponse.Redirect(string)" />.
    /// </summary>
    /// <remarks>
    /// The redirect location is added to the <see cref="ViewRedirectResult.ViewData" />
    /// with the key specified by <see cref="ViewRedirectResult.RedirectLocationViewDataKey" />.
    /// </remarks>
    public sealed class ViewRedirectResult : ViewResult
    {
        /// <summary>
        /// The key used to store the <see cref="RedirectLocation" /> in the
        /// <see cref="ViewRedirectResult.ViewData" />.
        /// </summary>
        public const string RedirectLocationViewDataKey = "RedirectLocation";

        private readonly string redirectLocation;

        /// <summary>
        /// Initializes a new instance of the <see cref="ViewRedirectResult"/> class.
        /// </summary>
        /// <param name="redirectLocation">The redirect location.</param>
        public ViewRedirectResult(string redirectLocation)
        {
            Validate.Argument(redirectLocation, "redirectLocation").IsNotNull().IsNotEmpty();

            this.redirectLocation = redirectLocation;
            ViewData[RedirectLocationViewDataKey] = redirectLocation;
        }

        /// <summary>
        /// When called by the action invoker, renders the view to the response.
        /// </summary>
        /// <param name="context">The context within which the result is executed.</param>
        public override void ExecuteResult(ControllerContext context)
        {
            context.HttpContext.Response.StatusCode = 302;
            context.HttpContext.Response.RedirectLocation = redirectLocation;
            base.ExecuteResult(context);
        }

        /// <summary>
        /// Gets the redirect location.
        /// </summary>
        /// <value>The redirect location.</value>
        public string RedirectLocation
        {
            get
            {
                return redirectLocation;
            }
        }
    }
}

You can then setup a new Redirect method in your base controller to create a ViewRedirectResult for you:

/// <summary>
/// Returns a <see cref="ViewRedirectResult" /> that redirects to the specified URL.
/// </summary>
/// <param name="url">The URL to redirect to.</param>
/// <returns>The <see cref="ViewRedirectResult" /> that redirects to the specified URL.</returns>
protected static new ViewRedirectResult Redirect(string url)
{
    var result = new ViewRedirectResult(url)
                 {
                     ViewName = "Redirect"
                 };
    return result;
}

All that remains is to create the Redirect view. We need this to be valid XHTML with a few extras to keep the SEO Toolkit happy; we need a content type, a description and a <h1>:

<%@ Page Language="C#" Inherits="System.Web.Mvc.ViewPage" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
    <head>
        <title>MrKWatkins - Object Moved</title>
        <meta http-equiv="Content-type" content="text/html;charset=UTF-8" />
        <meta name="description" content="This object has been moved." />
    </head>
    <body>
        <div>
            <h1>Object Moved</h1>
            <p>
                Object moved to <a href="<%= HttpUtility.HtmlAttributeEncode((string)ViewData["RedirectLocation"]) %>"><%= ViewData["RedirectLocation"] %></a>.
            </p>
        </div>
    </body>
</html>

Et voila. The content of your redirects is now valid XHTML and the spurious warnings from your SEO Toolkit report go away.

DataContext Inheritance

LINQ to SQL isn't bad. Apart from a few annoying bugs with the designer (i.e. The designer.cs getting deleted and not regenerated when you update the model if you have a partial code file and it's insistence on adding in connection strings all over the shop being the two biggest) and some missing features (proper many-to-many relationships) it's pretty good. We use it at work and it performs well. One thing that can happen if you're not careful though is you end up with a massive .dbml files that contain all the tables in your database. This can be less than ideal, especially if your application has several areas. For example you might work for a company that makes cars and boats. (Yeah I admit that's quite unlikely but please endulge me...) Both sections of the company would need access to customer information but the car guys wouldn't need details of the boats and vice versa. Rather than have one big DataContext with all the tables in is there anyway we could structure things a bit better?

The short answer is yes, thanks to the 'Base Class' property in the .dbml designer. (Click on the .dbml somewhere and have a look in the Properties window) Make youself a .dbml for your core entities, then make .dbmls for each of your other areas and set the 'Base Class' property for these 'child' .dbmls the core DataContext. So you might have a CoreDataContext that contains Customer entities and then a CarDataContext that has Car entities and a BoatDataContext with Boat entities. Both the CarDataContext and BoatDataContext will have access to the Customer entities but not to each other's entities.

Of course just doing that isn't that much use. The benfit of O/R mappers like LINQ to SQL is the easy use of relationships between entities. So for our Car.dbml to be useful we would like our Car entity to have a reference to a Customer entity. But if we load Car.dbml into our designer we will not see any entities from the parent Core.dbml. So how do we create the relationship?

Manually is the answer. If we inspect the designer file for a .dbml we can copy the code for a similar one-to-many property and tweak it for our use:

public partial class Car
{
    private EntityRef<Customer> _Owner;

    [AssociationAttribute(Name = "Owner_Car", Storage = "_Owner", ThisKey = "OwnerId", OtherKey = "Id", IsForeignKey = true)]
    public Customer Owner
    {
        get
        {
            return _Owner.Entity;
        }
        set
        {
            Customer previousValue = _Owner.Entity;
            if (((previousValue != value) || !_Owner.HasLoadedOrAssignedValue == false))
            {
                SendPropertyChanging();
                if ((previousValue != null))
                {
                    _Owner.Entity = null;
                }
                _Owner.Entity = value;
                if ((value != null))
                {
                    _OwnerId = value.Id;
                }
                else
                {
                    _OwnerId = 0;
                }
                SendPropertyChanged("Owner");
            }
        }
    }
}

We can now have an Owner property on our Car entity that we can use like a normal LINQ to SQL property:

using (var carDataContext = new CarDataContext(Connection))
{
    // Grab our Customer.
    var customer = carDataContext.Customers.Where(c => c.Id == customerId).Single();

    // Create a Car.
    var car = new Car
    {
        Registration = "T1 KARR",
        Owner = customer
    };

    // Save it.
    carDataContext.Cars.InsertOnSubmit(car);
    carDataContext.SubmitChanges();
}

But what about the other way around? What if the boat department what to get a list of all the boats a customer owns? I.e. can we get a Customer.Boats property? The answer to that is not really... The approach I tried was to define a subclass of Customer with the property and then replace the table in the DataContext. I.e. something like:

public sealed class BoatCustomer : Customer
{
    private EntitySet<Boat> _Boats;

    public BoatCustomer()
    {
        _Boats = new EntitySet<Boat>(new Action<Boat>(Attach_Boats), new Action<Boat>(Detach_Boats));
    }

    [AssociationAttribute(Name = "Customer_Boat", Storage = "_Boats", ThisKey = "Id", OtherKey = "OwnerId")]
    public EntitySet<Boat> Boats
    {
        get
        {
            return _Boats;
        }
        set
        {
            _Boats.Assign(value);
        }
    }

    private void Attach_Boats(Boat entity)
    {
        SendPropertyChanging();
        entity.Owner = this;
    }

    private void Detach_Boats(Boat entity)
    {
        SendPropertyChanging();
        entity.Owner = null;
    }
}

public partial class BoatDataContext : CoreDataContext
{
    public new Table<BoatCustomer> Customers
    {
        get
        {
            return GetTable<BoatCustomer>();
        }
    }
}    

Sadly this, and other similar approaches, don't work... InvalidOperationExceptions with messages like "Data member 'Int32 Id' of type 'KWatkins.DataContextInheritance.Customer' is not part of the mapping for type 'BoatCustomer'. Is the member above the root of an inheritance hierarchy?" start getting thrown around the place. The problem is that the attribute mapping doesn't look into base classes for some members. (If you open the lid with Reflector you'll see gratuitous use of the BindingFlags.DeclaredOnly enum value) So what are our alternatives?

1. Recreate the various properties of Customer entity in the BoatCustomer class. Not great; pretty soon we'd be back to large DataContexts with everything in. Kinda defeats the point of doing this whole DataContext inheritance thing in the first place!
2. Alter the AttributeMappingSource class so that it looks in base classes. Not really possible; all AttributeMappingSource does is return the class AttributedMetaModel. AttributedMetaModel does all the work but we cannot change it because it is internal.
3. Create a public version of AttributedMetaModel by using Reflector to get the original code then change it to look in base classes. Sadly not really an option either... There is a lot of code behind AttributedMetaModel that uses a lot of internal stuff from various areas of the framework. I started then gave up...
4. Create a MetaModel that acts as a wrapper around another MetaModel. We might then be able to wrap it around an AttributedMetaModel instance and intecept the relevant calls and change them accordingly. I didn't even attempt this one; if someone wants to try please be my guest...

In the end I settled on an extension method on Customer that returns a query:

public static IQueryable<Boat> Boats(this Customer customer, BoatDataContext dataContext)
{
    Validate.Argument(customer, "customer").IsNotNull();
    Validate.Argument(dataContext, "dataContext").IsNotNull();

    return from boat in dataContext.Boats
           where
                boat.OwnerId == customer.Id
           select boat;
}

(See this post for details about the Validate class) This method returns a query that returns all the Boats for a Customer. Sadly it's not a proper EntitySet so we can't add and remove members from it. But I haven't found this to be a major problem; I usually use properties like this for querying rather than inserting/deleting so it hasn't bothered me much. It's a shame we have to pass in a BoatDataContext but LINQ to SQL entities don't have a reference to a DataContext so there isn't much we can do.

There you go. By use of inheritance you can help split up your .dbml files and not end up with one massive, unwieldy DataContext. Feel free to download some example source code that demonstrates all of this. Note that I used Visual Studio 2010 to write it though; I wanted to see if some of the LINQ to SQL bugs have been fixed. (The .designer.cs classes getting deleted I mentioned above seems to have been fixed) You'll therefore have to setup your own projects if you want a VS2008 version...

Making NUnit Play Nicely With Team Foundation Server

UPDATE! The code from this article has now been integrated into the NUnit for Team Build project. See NUnitTFS Integrated With NUnit For Team Build for more information.

My company has just started using Team Foundation Server. And whilst it is awesome in many ways it's support for testing frameworks other than MSTest is a bit rubbish. Well completely non-existent actually. Unless your test results are in the MSTest format then you're not going to be uploading them to TFS anytime soon. Fortunately others have already come across this problem... There is a project on CodePlex called NUnit for Team Build that is basically an XSL transform to take results from NUnit and transform them into MSTest's format.

However we still have to get those results into TFS. Which means a manual upload from Visual Studio or using MSTest with a few well chosen command line arguments. So if you want to automatically upload tests from your build server to TFS you'll need to install MSTest on your build server. MSTest isn't exactly and easy-to-install self contained tool so you're either gonna have to stop copying random assemblies around until it works or install Visual Studio on your build server. Bollocks to that!

Given that TFS is supposed to be all nice and web servicey it shouldn't be too hard to write something to upload the results to TFS should it? Well it's gonna be a little tricky; the web services in question aren't documented by Microsoft and they don't really like people reverse engineering their stuff. (Plus I've had a quick peek with Reflector and there is a lot of code to wade through...) Given that it's all web services why don't we arm ourselves with Fiddler and see what MSTest is doing exactly?

The first thing to notice is that MSTest adds build information to your .trx file. Try uploading an MSTest run then downloading the run and comparing the two .trx files; you'll notice it adds a element called Build just before the TestDefinitions element:

<Build flavor="Release" platform="Any CPU" />

This just contains the build properties you specified with the /flavor and /platform switches when calling MSTest. Simple enough to add.

The first web service call MSTest makes is a call to the QueryBuilds method of /Build/v2.0/BuildService.asmx to get some information about the build we identified with the /teamproject and /publishbuild switches when calling MSTest. This service gives us (amongst other things) a build ID that we will need to call other web services later on.

The next step is a call to the GetVersion method of /Build/v1.0/PublishTestResultsBuildService2.asmx to get the version of the publish web service. I never used this information in my final application; I had the publish version hardcoded. If you were working with another version of TFS (I'm using 2008) then you might need to do something with this information. I've left the call in for completeness sake.

Now we can publish. Publishing involves three steps:

1. A call to the PrepareToPublish method of /Build/v1.0/PublishTestResultsBuildService2.asmx to tell TFS that we want to publish some test results. We give it the build ID we retrieved earlier and the run ID for the test. (A random GUID in the test result XML) The web service returns a directory on the build server where we should copy our test results to.
2. Copy the .trx file to the directory we've just been given.
3. A call to the PublishRun method of /Build/v1.0/PublishTestResultsBuildService2.asmx to tell TFS that we've copied the results across. We give it the build and run IDs along with the filename of the file we've copied.

And that's it. Pretty easy to do ourselves in a little application wouldn't you say? Which is exactly what I've done. You lucky people!

Feel free to download the source code and give it a try. It's a simple console application that you can call from your TFSBuild.proj file when doing an automated build. It also includes an updated version of the XSL from NUnit for Team Build that fixes a couple of problems, namely names for TestCases and names over 255 characters. (Which TFS really doesn't like and will happily fail when you upload tests without telling you why causing you to rip out half your hair and go insane. TFS can be a right tosser at times.) The arguments are as follows:

I've used the excellent CommandLine Parser library to parse the arguments; I've used the library a few times now in private projects and recommend you give it a try.

Note that you'll also need to update the configuration file with the location of your TFS; I never bothered to write code to create the WCF configuration on the fly using a command line option...

So how do you go about using it with automated builds? Well I have a folder called Build in the root of my project. In that I have the TFSBuild.proj an a folder called NUnitTFS with the NUnitTFS.exe and associated files in. You can then simply call it from your build script using the Exec command:

<Exec Command="&quot;$(SolutionRoot)\Build\NUnitTFS\NUnitTFS.exe&quot; -n &quot;$(OutDir)NUnitOutput.xml&quot; -t &quot;$(TeamProject)&quot; -b &quot;$(BuildNumber)&quot; -f &quot;Release&quot; -p &quot;Any CPU&quot; -x &quot;$(SolutionRoot)\Build\NUnitTFS\NUnitToMSTest.xslt&quot;" />

I'll leave it to you to wrap the task in a nice build step. Didn't expect the moon on a stick did you?

Note that I've only tested this using my company's setup; there is no guarantee it will work anywhere else! That's why I've included the (not very polished) source code, so you can tweak things if necessary. If you do fix any problems please drop me an email so I can update the code; I intend to publish it on CodePlex when I get a chance.

Fluent Argument Validation Part 5 - Version One

So that's it for fluent argument validation for the time being. I've got enough done to spit out version one, which is more than enough for my current needs. Afraid you don't get the source just yet... I plan to host the source on CodePlex eventually but I might just wait for version two for that...

"Version two?" I hear you say. "But what is wrong with version one?" Nothing, really. It suits me quite well. However whilst writing these articles (I'd actually written the library several months before...) I've thought of several ways to improve the thing...

Improve Number Chains

I touched on this one in part three. Currently the following is perfectly acceptible:

public static void SomeMethod(int number)
{
    Validate.Argument(number, "number")
        .IsGreaterThan(5)
        .IsGreaterThan(3)
        .IsGreaterThan(3);

Now are you ever going to validate a number is greater than another number twice? Surely you'd just validate it against the higher of the two. Therefore should I allow more than one call to IsGreaterThan in a validation chain?

Okay, you might be validating against variables and therefore have to validate against two variables to check they are greater than both. But in this case I think we need a different method anyways because one would want the exception method to express that the argument has to be greater than the variable rather than the current value of the variable. For example the following code:

public int SomeProperty
{
    get
    {
        return 5;
    }
}

public static void SomeMethod(int number)
{
    Validate.Argument(number, "number")
        .IsGreaterThan(SomeProperty);

would give the error message "Value must be greater than 5." A more useful message would be "Value must be greater than SomeProperty.". So perhaps we need another set of methods that allows you to specify something (other than a constant) to validate against?

Improve The Fluent 'Sentences'

The English made by reading the Fluent validation could be a bit better. For example the following:

Validate.Argument(value, "value")
    .IsNotNull()
    .IsNotEmpty()
    .StartsWith("Something");

would sound better as:

Validate.Argument(value, "value")
    .IsNotNull()
    .OrEmpty()
    .AndStartsWith("Something");

Default Tolerance

Unless you specify a tolerance then currently the validation methods for imprecise numbers don't use a tolerance which basically means they're not very useful; in general they will fail for some valid cases. NUnit's constraint model, which is a great example of a good fluent interface, has a default tolerance to use in imprecise comparisons. I think my library should do that too...

More Than Arguments

I'd like to add more validation than just arguments, e.g. type parameter validation, IO validation, XML validation, etc..

Anyways...

I'm sure I'll think of lots more for version two. But in the meantime version one is finished. Have a look at parts one, two, three and four if you haven't already. Feel free to download the library and use it in your own projects. If you do find the library useful then please ping me an email with details of the project you used it on and any ideas you have for improving it. And if you use it to make loads of cash then feel free to donate. No, in fact, feel compelled.

Fluent Argument Validation Part 4 - Enums

I've been creating a fluent argument validation library; see parts one, two and three if you need to catch up.

Generics are brilliant. Wonderful things. But there are a couple of things about them that annoy me. For example, why can't I do the following?

public class SomeClass
{
    public void SomeMethod<T>(T value) where T : class...
    
    public void SomeMethod<T>(T value) where T : struct...
}

I.e. use a different method overload depending on whether my type is a reference or a value type? A type cannot be both a reference and value type at the same time so surely we have two different method signatures? Yes, I know there are good reasons why not. But still... I want to be able to do this!

Another one that annoys me (and is relevant to this post!) is not being able to to specify my type must be an enum, i.e. something like:

public void Argument<T>(T value) where T : enum

I want to be able to create a validation method that checks if an enum value is defined. But that the same time I don't want to have people pass any value type they like in. Whilst I can quite happily check at runtime that a type is an enum it just feels like something I should be doing at compile time...

Of course what makes this really annoying is that you can specify an enum as a type constraint in IL! Whilst I'm quite happy for C# to restrict me in some ways (e.g. in IL you can throw an object of any type whereas C# restricts it to Exception and sub-classes) this one I'm not happy about. Mainly because it affects me personally, I'll admit. But is that not a good enough reason?

Guess I could rewrite the thing in a language that does allow it. Nah. I like C#. I could write my own language that is an extension of C#. Whilst I'd like to do that one day I think it might be overkill for this... What if I decompiled the assembly the C# compiler generated and changed the offending line? That might work... C# would have to respect the type constraint even if it cannot be expressed in C#. Let's try that...

Turns out it works too. Almost. Turns out I bump into my first generic annoyance, that of methods with the same signature but different type constraints. So I cannot do the following pseudo-C#:

public class Validate
{
    public void Argument<T>(T argument, string parameterName) where T : class...
    
    public void Argument<T>(T argument, string parameterName) where T : enum...
}

Guess I'll just have to live with that one and create an EnumArgument method on my Validate class. So what IL do I need to rewrite? Well firstly I'll have to rewrite the initial generic method on my Validate class. Luckily IL method signatures are fairly readable. The C# method signature:

public static IEnum<T> EnumArgument<T>(T argument, string parameterName) where T : struct

Becomes:

.method public hidebysig static class KWatkins.Validation.Argument.IEnum`1<!!T> 
        EnumArgument<valuetype .ctor ([mscorlib]System.ValueType) T>(!!T argument, string parameterName) cil managed

The type constraints are quite complex compared to C#. The type has to be a value type, has to have a parameterless constructor and has to inherit from System.ValueType. C# hides the second two things from us as in C# we can infer that if something is a value type then it must have a parameterless constructor and inherit from System.ValueType. Anyways its simple enough to change this to have an enum type constraint:

.method public hidebysig static class KWatkins.Validation.Argument.IEnum`1<!!T> 
        EnumArgument<valuetype .ctor ([mscorlib]System.Enum) T>(!!T argument, string parameterName) cil managed

Done. Change ValueType to Enum and walk away. Nice and simple. I also have to rewrite the IL on the class that actually does the validation but that's basically the same replacement as above.

How do I rewrite the IL though? Luckily .NET comes with a tool called ildasm that decompiles any given assembly into IL. And then Visual Studio comes with a tool called ilasm that compiles IL into an assembly. Therefore I can create a command line application that can run as a post build command for my validation assembly. It can call ildasm to disassembly the assembly, do some crude string replacement on the IL and then pass it back into ilasm to turn the thing back into an assembly.

And that's that. I now have a Validate.Argument<T> method that will only accept an enum for it's type parameter. And that's pretty much it for the vaguely interesting stuff in my argument validation library too. So I'll wrap things up for version one of the library in the next post.

Fluent Argument Validation Part 3 - Numbers

In parts one and two I discussed the approach I'm going to make to create a fluent argument validation library. Now the implementation.

Well it turns out most of it is pretty straightforward. And a little boring. There are a couple of things that warrent comment, the first being numbers. There are a lot of number types in .NET. There are precise types; byte, 3 sizes of int and decimal. Plus of course their evil partners the unsigned ints and the signed byte. And then on top of that you have imprecise types, the single and double. For the sake of completeness I'm going to add validation methods for all of them. Which means a lot of code to write; numeric types don't have a common interface we could exploit, or anything like type classes we can operate on. How can we be lazy and write less code?

By auto-generating it of course. One of the best kept secrets in Visual Studio is the Text Template Transformation Toolkit, or just T4 for short. T4 is a code generator that builds code from templates. I first heard about it in a blog post by Scott Hanselman a while ago and it's nice to finally have a chance to use it!

But before we get generating, what sort of interfaces/methods will we need? Basic range checking, greater than, less than, etc., will be needed for all number types. I find myself having to validate numbers are positive a fair bit so I'm going to add quick methods to check for positive and negative. These are only necessary for the signed types; there is no point in checking to see if a uint is negative because it cannot be. It sounds like we immediately have two interfaces, one for signed types and one for unsigned. Both contain greater/less methods but the signed one also contains positive/negative methods

As discussed in part one one of the problems I had with some of the other fluent interfaces available is that they allow you to make non-sensical and/or pointless calls, e.g:

public static void SomeMethod(int number)
{
    Validate.Argument(number, "number")
        .IsPositive()
        .IsNegative()
        .IsNegative();

A number cannot be both positive and negative, and there is no point in checking a number is negative twice. Therefore my inteface needs to return the interface for validating unsigned types after a call to positive or negative. (Even for singles and doubles! So if I talk about unsigned doubles I am making sense. Honest.) Ideally we would also like to stop calls such as:

public static void SomeOtherMethod(int number)
{
    Validate.Argument(number, "number")
        .IsGreaterThan(5)
        .IsGreaterThan(3)
        .IsGreaterThan(3);

There is no point in checking if something is over both 3 and 5 as just checking 5 would be enough. Similarly checking 3 twice is not necessary. Unlike the positive/negative we cannot enforce this at compile time so I'm going to have to let this one slide. (Although I will come back to this in part five)

The only other methods I'm going to implement are for the imprecise types only. These will be overloads of all the methods so far but with a tolerance to allow us to check two imprecise numbers follow the condition within a given amount.

Now how does T4 come into play? Well I can define generic interfaces for all the methods but I will need concrete classes for each numeric type. These concrete classes basically have the same implementation (operator comparisons such as >, <=, etc.) so instead of duplicating the same code over and over I'll create a template that generates the methods for each numeric type. If we can define the various properties of our numeric types (e.g. signed/unsigned, precise/imprecise, etc.) then our template can query those definitions to work out what interfaces and methods need implemented.

Definitions of the numeric types could come in handy in future templates. Therefore I defined the details of the numeric types in a file called NumericTypeDefinitions.ttinclude, which looks something like:

<#
    var numericTypes = new []
    {
        new
        {
            Name = "Byte",
            Zero = "0",
            CLSCompliant = true,
            Signed = false,
            Precise = true
        },
        new
        {
            Name = "Decimal",
            Zero = "0m",
            CLSCompliant = true,
            Signed = true,
            Precise = true
        },
        ...

Sadly the syntax highlighting is mine; rather annoyingly VS2008 doesn't highlight .tt or .ttinclude files... We can include this file in our actual T4 template. Basic templates just have a blob of code. The include means our definitions will be added to this blob. (You can create custom generator classes for more complex templates) Our T4 file will look something like this: (the ASP.NETters amongst you will probably recognise some of the syntax)

<#@ template language="C#v3.5" #>
<#@ output extension="cs" #>
<#@ assembly name="System.Core.dll" #>
<#@ import namespace="System.Linq" #>
<#@ include file="NumericTypeDefinitions.ttinclude" #>
using System;
using KWatkins.Validation.Argument;

namespace KWatkins.Validation
{
    public static partial class Validate
    {
<#
    // Partial part of Validate first.
    foreach(var type in numericTypes.Where(t => t.Precise))
    {
        if (!type.CLSCompliant)
        {
#>
        [CLSCompliant(false)]
<#
        }
#>
        public static <#= GetInterfaceType(type.Signed, type.Name) #> Argument(<#= type.Name #> argument, string parameterName)
        {
            return new <#= type.Name #>Validation(argument, parameterName);
        }
<#
    }
#>
    }
}
...

What's happening here? Well we're basically adding the method Argument(T argument, string parameterName) to our Validate class. The directives at the start of the template define what we need for the code in our template, e.g. the language our template uses, the assemblies and namespaces we want to use, etc. Then the template starts; the text in grey is the text that will appear in the generated .cs file. In the snippet above I am looping through all the precise numeric types. If they are not CLS compliant then I add a CLSCompliantAttribute to the method. I then spit out the method definition, which returns a validation class of the appropriate type, casted to an interface of the appropriate type. I'll spare you the rest of the details; you can have a look at the source when I've finished.

Now the tests! How on Earth are we gonna test generated code? We could I suppose test the generator itself, i.e. test the output created by our T4 template is correct. But this doesn't actually test our final validation code! We could write a test for each generated method. But that would take ages besides being a bit rubbish. We could auto-generate our tests using a T4 template. Not a bad idea, but I personally prefer to have my test code as different to my code being tested as possible. So how to avoid writing a thousand separate tests for all our generated methods?

Use NUnit 2.5's excellent new generic test fixtures! NUnit 2.5 allows you to use generic classes for your test fixtures. You can then specify multiple TestFixtureAttributes each with a different generic type. The fixture will be executed multiple times, one for each TestFixtureAttribute. Add a splash of reflection to create our T4 generated validation class and we can write test fixtures like this:

[TestFixture(typeof(Byte))]
[TestFixture(typeof(UInt16))]
[TestFixture(typeof(UInt32))]
[TestFixture(typeof(UInt64))]
public class UnsignedPreciseNumberTests<TNumber> : NumberTests<TNumber>
    where TNumber : struct
{
    [TestCase("5", "TestParameterName", "10",
        ExpectedException = typeof(ArgumentOutOfRangeException),
        ExpectedMessage = "Value must be greater than 10.\r\nParameter name: TestParameterName\r\nActual value was 5.")]
    [TestCase("5", "TestParameterName", "5",
        ExpectedException = typeof(ArgumentOutOfRangeException),
        ExpectedMessage = "Value must be greater than 5.\r\nParameter name: TestParameterName\r\nActual value was 5.")]
    [TestCase("5", "TestParameterName", "0")]
    public void IsGreaterThan(string argument, string parameterName, string minimum)
    {
        IUnsignedPreciseNumber<TNumber> validator = IUnsignedPreciseNumber<TNumber>)CreateValidationType(argument, parameterName);
        validator.IsGreaterThan(ConvertFromString(minimum));
    }
    ...

Here we are testing the IsGreaterThan method for the unsigned, precise number types. The test method gets an instance of the validation type using the CreateValidationType which does some reflective magic to create the correct type. It then calls the method using the values passed into the method via NUnit 2.5's TestCaseAttribute which allows you to run the same test multiple times with different values.

So that is the numbers done. I urge you to have a play with T4 and NUnit 2.5; both are fantastic tools to have in your arsenal. In the next post I will get irritated with enumerations...

Fluent Argument Validation Part 2 - The Approach

As covered in part one I have decided to create a fluent library for validating arguments as I wasn't happy with ones currently available. But what exactly do I want?

• To explicitly state that we are validating arguments
• To validate that the user has not passed in a null or empty parameter name
• To specify the argument and parameter name once and then be able to chain a series of validations
• To not have to specify when to validate (e.g. with a .Check() or .Validate() method)
• To stop the user chaining non-sensical validations together, where possible

Which gives a syntax something like this:

public static void SomeMethod(string stringValue, int intValue)
{
    Validate.Argument(stringValue, "stringValue")
        .IsNotNull()
        .IsNotEmpty();
        
    Validate.Argument(intValue, "intValue")
        .IsPositive()
        .IsLessThanOrEqualTo(5);

Why have I created a class called Validate with a property called Argument rather than a class called ValidateArgument? This is so I can expand the library to validate other things apart from arguments, all from the same starting point. For example I could expand it to do things like:

public static void SomeOtherMethod<TEnum>(TEnum enumValue, string directory) where TEnum : struct
{
    Validate.TypeParameter(typeof(TEnum), "TEnum")
        .IsEnum();
        
    Validate.Directory(directory)
        .Exists()
        .IsEmpty();

So, how am I going to actually code this thing? Well if I'm going to chain these validations together then I will need to store the argument and parameter name somewhere. There are a two obvious ways to do this:

1. Store them in a field somewhere. This would need to be a thread safe; threading issues are hard enough to debug at the best of times without argument validation giving you apparently false exceptions...
2. Create an object to hold them in. However the methods in the chain will need to change depending on depth; we don't want to allow two calls to IsNotNull() in a row for example. Therefore we are either going to need to create a new object when the methods in the chain change or create one object that implements multiple interfaces explicitly and then cast it to a different interface when then methods in the chain change. And should our objects be structs or classes?

Which way is best? Are any methods intrinsically worse for some reason? Performance is a good reason. Whilst I'm a firm believer that you should get you application working and performance enhance after (slow code is better than no code!) I also think prototyping is a good idea. If we can do a simple test at this stage then we might well find out that one approach is fundamentally slower than the others.

So I've knocked together a simple application to test each method and see which is quickest; feel free to play with the source code. It measures how long it takes to validate a string argument is not not null and not empty 25,000,000 times, compared against two not so fluent methods. On my PC the results are: (times in seconds)

So it looks like the single class approach wins. A few things to note though:

• This test is for two chained calls; I suspect we might find a using structs is faster for a single call. But then one of the points of this library is that you can chain methods... Besides I seem to spend half my life validating strings for not null and empty so I reckon my code will be using chains of two or more items quite a lot...
• Not as fluent, separate methods is fairly close to the single class approach. This might be because it has to validate that the parameter name is not null or empty twice whereas the single class approach only has to do it once.
• Although creating multiple structs is quicker than multiple classes (as you'd expect; in the current .NET implementation local structs are allocated on the stack so there is no need to garbage collect them and perform all the tracking that goes with that) creating a single struct isn't. This is due to boxing. Interface methods are defined as being virtual but structs simply don't have it in them to handle that (they're missing a vtable to lookup the virtual methods) so they get boxed, giving us the performance hit.
• The CLR team have clearly optimised the crap out of ThreadStatic fields given that they're 20 times faster than using named data slots.

So I have an approach. In the next post I'll start to look at implementing it.

Fluent Argument Validation Part 1 - The Competition

I like fluent interfaces. And I'm very pedantic about validating arguments. So I went looking for a fluent interface for validating arguments. And I found a few, but none were quite what I'm looking for. So yup, I decide to write my own.

Before explaining how I did that though I would like to mention a couple of those and explain why they are not what I'm after; hopefully that will help to why I felt the need to write my own.

Paint.NET

An excellent article on the Paint.NET blog gives details of one approach. Whilst taking care to optimise for the non-exceptional path (no objects are created unless validation fails) it didn't feel fluent enough for me. An example of the interface given is:

public static void Copy<T>(T[] dst, long dstOffset, T[] src, long srcOffset, long length)
{
    Validate.Begin()
        .IsNotNull(dst, "dst")
        .IsNotNull(src, "src")
        .Check()
        .IsPositive(length)
        .IsIndexInRange(dst, dstOffset, "dstOffset")
        .IsIndexInRange(dst, dstOffset + length, "dstOffset + length")
        .IsIndexInRange(src, srcOffset, "srcOffset")
        .IsIndexInRange(src, srcOffset + length, "srcOffset + length")
        .Check();

For me a fluent interface should allow you to specify something, and then let you chain a sequence of operations on that something. jQuery is the an excellent example of a good fluent interface; you specify an element and then perform a chain of actions on that element. For argument validation I would expect us to specify an argument and then chain a sequence of validations on that element. Which is why I don't feel this interface is fluent enough for me. It does not specify an argument at the start, but rather it specifies the arguments each time. Consider the following example of the above style:

public void DoSomething(int? argument)
{
    // Check argument isn't null and is between 0 and 100.
    Validate.Begin()
        .IsNotNull(argument, "argument")
        .IsGreaterThanOrEqualTo(argument, "argument", 0)
        .IsLessThanOrEqualTo(argument, "argument", 100)
        .Check();

Doesn't seem much point to me in chaining the methods if we keep having to specify the argument and parameter name each time.

Of course there are valid reasons for this; if we don't specify the argument and parameter name each time then we are going to have to store them somewhere and that means a tiny performance hit; you're gonna need to set a field or create and object or do something to store that information. For an application like Paint.NET that needs every ounce of performance that could well be a problem.

For my interface I'm willing to take a tiny performance hit to get the interface I want. If I have to create a short lived object or set a field then I'm not too fussed about that to be honest. I find there are a lot of people who would moan about such things. Sometimes for good reason. But more often they'll complain that I should use a byte instead of an int whilst at the same time think that boxing is a sport and an expression tree is a plant that smiles. If I've optimised every other area of my application and actually need to get a bit of extra performance then I'll be a happy man. And I'll just drop the argument check...

Roger Alsing's Argument Validation Framework

Roger Alsing has a good approach. Much more fluent; we only specify the argument once:

public static string ValidationFunc(int a, string b, DateTime c)
{
    a.Require("a")
        .IsGreaterThan(10);

    b.Require("b")
        .NotNull()
        .NotEmpty()
        .LongerThan(2)
        .StartsWith("Ro");

I have two main problems with this approach:

1. Making Require an extension method on object; what if my object isn't an argument? What if it's a field or a local object? Admittedly it also has an overload without the parameter name (i.e. a.Require()) so it can be used as a general validation method. But I would prefer to be explicit about the fact that we're validating an argument.
2. There doesn't seem to be anything to prevent you doing something silly. And programmers often do silly things; we should try to stop them wherever possible.. For example, the following are allowed:
   
   b.Require("b").NotNull().NotNull().NotNull().NotNull().NotNull().NotNull();

a.Require("a").IsGreaterThan(4).Require("b").NotNull();

.NET Junkie

.NET Junkie outlines a similar approach. The article talks about the relationship to Spec# which gives some more info on why the interface is created like it is. I just want to validate my arguments in a nice fluent way which are my pre-conditions. As for post-conditions my method code should be doing that!

Code Contracts

Awesome but not released yet. 8o)

In the next post I'll start to plan out what I want from the fluent interface and start thinking about the best way to get it.