A couple of days ago, I had to do some simple date and time validation using regex. The format to validate was yyyy-mm-dd hh:mm. It looks simple enough and like always, I thought I could find the regex on the web, but I couldn’t.

I was under a tight deadline and the date/time validation was not that important, so I made a decision to make the worst regex the world have ever seen. Maybe it’s long, ugly and wrong, but it works just enough to make me use it until I have the time to make a better one.

Warning, do not try this at home!

[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9] [0-9][0-9]:[0-9][0-9]

The good thing about regex is that they are always ugly, most of them are long and only five people in the world understand them enough to see if they work or not.


In some situations it can be important to know which methods are calling other methods. Think of an error log. Here you would like to know which method that threw the error and at what line in what file. This helps to debug runtime code and makes it very easy to find the exact point of failure.

C# 2.0 has the possibility to go back in time and inspect which methods called other methods all the way up the stack. Here is a static method that does just that and returns the caller of any method in the stack.

/// <summary>
/// Retrieves the caller of any method in the stack.
/// </summary>
/// <param name="skipFrames">How many steps to go back up the stack.</param>
/// <returns>The method name, file name and line number of any caller.</returns>
public static string GetCaller(int skipFrames)
  System.Diagnostics.StackFrame sf = new System.Diagnostics.StackFrame(skipFrames, true);
  string method = sf.GetMethod().ToString();
  int line = sf.GetFileLineNumber();

  string file = sf.GetFileName();
  if (file != null)
    // Converts the absolute path to relative
    int index = file.LastIndexOf("\\") + 1;
    if (index > -1)
      file = file.Substring(index);

  return method + " in file " + file + " line: " + line;

In a error logging scenario you probably want to set the skipFrames parameter to 1, which is the latest method or the method highest on the stack.


When Visual Studio 2005 was released together with ASP.NET 2.0, the web project model was totally changed from the ASP.NET 1.x model. It took some time for me to get used to it, and in the beginning I didn’t like it much. Apparently, I was not alone and Microsoft got a lot of mail from developers who wanted the old Web Application Project (WAP) model back. Visual Studio 2005 Service Pack 1 then reintroduced the WAP model.

I never really understood why so many people wanted the old model back, because it has some serious inconveniences. My guess is that almost all of the people who wrote Microsoft wasn’t web developers to begin with, but maybe had a past doing Windows Forms to which the WAP model bares many similarities.

No change 'n review

Old school web developers like to make a small change and then see how it looks and continue to do so an awful lot of times. The WAP model doesn’t allow you to do quick changes and review them at once. You first have to compile the entire project and that can easily take 30 seconds for larger web projects. At work, we have a web project that takes 3 minutes to build.

That quickly gets very annoying and is just a waste of time. The Web Site model does not have that problem.

No quick ‘n dirty editing

In the WAP model, if you don’t have Visual Studio you cannot change anything but the layout and that is really annoying. When I’m away from my Visual Studio and finds something I want to change, then I’m not able to. The Web Site model on the other hand allows me to change anything I want using only Notepad and the build-in FTP capabilities of IE.

Annoying deployment

The initial deployment in the WAP model is easier because there are fewer files to be FTP’ed to the remote location. But if you want to make a small change and deploy it, then you have to FTP the dll file which can be several hundred kilobytes. Now you think: how can that be a problem on your super broadband connection? Well, it can if I’m doing small changes an awful lot of times and need to upload them to review them. Then that extra 5 seconds of upload time just get on my nerves.

In the Web Site model you just upload the file you changed. That’s 2 kilobytes versus 200 kilobytes.

What I’m trying to say is, that I don’t understand the popularity of the WAP model…


If you have added some ASP.NET validators to a webform, you might want to run them before hitting the submit button. In BlogEngine.NET we need to run the validators when a new comment is about to be added, but because it is using AJAX to post the comment we don’t submit the form.

The form is only used to take advantage of the validators and the server controls such as TextBox and they are still needed for clients that don’t support AJAX. What we needed was a way to validate the page from a custom JavaScript function.

Whenever a validator is added to a webform, a reference to the WebResource.axd JavaScript file is added as well. In here is all the mechanics used to do client-side validation and a lot of other useful things. It holds a function called Page_ClientValidate() which runs all the validators and returns true if all validators validates, otherwise it returns false. It also makes sure to show the error message of the validators that fail.

You can use it from within a button by specifying the onclick client-side event like so:

<input type="button" value="Save" onclick="if(Page_ClientValidate()){DoSomething()}" />  

If the Page_ClientValidate() function returns false, nothing happens and the error message of the individual validators that failed is shown. If it returns true, then everything validates and you can proceed. Just remember to do a manual server-side validation as well.


I’ve been using Visual Studio 2005 for almost 2½ years since the beta 1 release. In all that time, I’ve used Firefox and Firebug for all JavaScript debugging. I’ve tried setting breakpoints in JavaScript in Visual Studio before, but I never got it working so I left it for Firebug. Then the other day, our new developer at Traceworks told me that Visual Studio could be used for debugging and that it is possible to set breakpoints in the JavaScript files.

This of course illustrates that I’m slow – 2½ years slow to be exact. For those of you, who are as slow as me, keep reading and I’ll tell you how to debug JavaScripts in Visual Studio.

Set up Internet Explorer

Internet Explorer has disabled the possibility to debug scripts by default, so the first thing to do is to enable it. In the top menu, go to Tools -> Internet Options -> Advanced. Here you need to remove the checkboxes in Disable script debugging. This is needed for Internet Explorer to tell Visual Studio about the JavaScript running in the browser.

Start debugging

In included .js files you are now able to set break points as you normally would in C# or VB.NET. The execution stops at the break point and you are able to see the values of the variables and to move forward by hitting F10 and F11 like normal. The experience is exactly the same as debugging C# code.

For inline JavaScript you cannot set break points, but Microsoft did provide us with an alternative. If you add the word debugging wherever you want in the script code, the execution will stop at the word and you can debug exactly the same way as setting a break point.

For this to work, you must run Visual Studio in debug mode. That’s it, extremely powerful and easy to do. The only thing I don’t like about this is that I didn’t know about it before now. C’est la vie.