This was driving me nuts earlier today, so this post is a kind of reminder to myself not to forget this again:

When using Routing in .NET 4 always remember to add exceptions for axd files!


In my case I could not get standard .Net Field Validation to work client side. It was simply failing, not firing up, kaputt!

This was an old Web Site project that I had not touched in over a year. The last few days I have upgraded it from .NET 2.0 to 4.0, upgraded the Visual Studio solution from VS2008 to VS2010, made a lot of functionality and programming changes and only today discovered that Field Validation was not working anymore 🙁
I tried to trace my steps but I had just made too many changes to figure out just what was causing this.

I spent hours testing and googling. I made the simplest pages with a single RequiredFieldValidator. I played around with ValidationGroup, EnableClientScript and all the properties you can think of, changed just about everything in web.config etc etc. But I could not get it to work in this particular Web Site project. Finally I used the Chrome built-in Developer Tool and saw a few lines like this:

Failed to load resource: the server responded with a status of 404 (Not Found)

WebResource.axd is basically Javascript libraries that contains .NET functions for things like Field Navigation, Tree View and Ajax.
Anyway, once I found this I spent another hour or so googling and testing before I finally remembered I had just implemented Routing the other day, added the ignore exception mentioned above and – bingo it was working again. 🙂

In a way something good came out of this because, when client side validation fails it will rely only on server side validation and that means another thing you should never forget – to always add at the top of your button click event:

If Not Page.IsValid Then Exit Sub

I had forgot this, which meant that when my client side field validation – which I had relied on in the past – did not work, my script just kept going even though the fields did not validate. Of course, forgetting this opens up for all kinds of attacks from users who simply block javascript.

(I’m sure all this is already in some best practice document somewhere)