Archive for February, 2007

It is often overlooked, but Response.Redirect has an overloaded method which has two parameters.

The first is like the overloaded version which gets only one parameter – the URL to redirect to.
The second is whether to end the request now or let it complete and only then redirect.

By default when calling the first version:

Response.Redirect(“http://somewherenice.com”);

It will actually call the following code:

Response.Redirect(“http://somewherenice.com”, true);

This means that the request will end right after the execution of the Response.Redirect function and no other code that is hooked to events that occur after the place in which you called Response.Redirect will execute.

For example, if you have a certain code at the Page_PreRender event and you are calling Response.Redirect in the Page_Load event (either on the page or in a control on the page), without using the overload version of Response.Redirect that gets two arguments and setting the second argument to “false”, the code in the Page_PreRender event will never get called.

While this seems very trivial, there are a lot of bugs that sometimes occur because people forget the Response.Redirect with one parameter stops the execution of the request.

Every time you call Response.Redirect, stop for a second and think if you really want to end the request at that point or let it continue to process until it finishes.

If you want it to continue processing the page and perform the redirection after the processing is done use the following code:

Response.Redirect(“http://somewherenice.com”, false);

Thinking 2 seconds before writing a Reponse.Redirect code can save a lot of minutes debugging and figuring out that you never reach the other code because the request ended at the Response.Redirect call.

UPDATE: Fixed the last sample, thanks to Eber Irigoyen

Sometimes you need to to debug something that is simply doesn’t work as it should. It doesn’t throw an error so it’s a bit trickers to debug it with WinDbg or MDbg. In addition to that, you simply cannot (or should not) install a full blown Visual Studio installation on that machine.

For these scenarios exactly, Visual Studio’s remote debugging abilities exist.

At work, a friend had to debug such a problem. It didn’t throw an error and it worked on his machine (it always works on the developer’s machine 😉 ) but didn’t work on one of our test servers.

In order for the remote debugger of Visual Studio to work, one must install the Remote Debugger package that comes on the Visual Studio DVD on the remote computer. It’s a relatively small footprint installations.

NOTE: Be sure NOT to install this on a production server since the remote debugger needs to somehow talk to your debugger and it uses the network for that. Installing this (or at least keeping it enabled) on a production server might put the server at risk of being hacked!

Installing is the easy part. Now comes the configuration part since the debugging service authenticates both ways (both the machine running Visual Studio needs to authenticates on the remote machine, and the remote machine needs to authenticate on the machine running Visual Studio)

I’ve found two interesting article that can help you do that. One is a Knowledge Base article from Microsoft, the other a blog post for figuring out how to configure things when you are running in a domain-less (or domain different) envrionment:

  1. How to implement remote debugging in Visual Studio 2005
  2. Remote Debugging without domain accounts – from greggm’s blog.

If you follow these two articles you’ll get it up and running in no time.

If all else fails, printf debugging will probably still work (I’m referring to the broader definition of printf debugging which includes logging to a file/event log/whatever and not actually using printf’s to log stuff).

Perhaps its just another case of RTFM but I might have a point here. Really.

I was using AJAX.NET and wanted to attach some silly handler to the “onmousedown” event of a link (“<a href”). I used the nice little $addHandler method in the following syntax:

$addHandler(myElement, “onmousedown”, myHandler);

And to my surprise it didn’t hook up anything.

I did what any developer would do, plunged back to the documentation and after a bit of a careful reading I saw the following line:

“The eventName parameter should not include the “on” prefix. For example, specify “click” instead of “onclick”.”

Now why should I care if I’m writing “onclick” or “click”. The convention used in browsers is “onclick”, after all that’s what you put on an element if you want to add an “onclick” handler in HTML.

Why would anyone want to break this convention. And even if you do decide to break it, adding a simple “if” or checking for the characters “on” at the start of the string and removing them would be nice.

Anyhow, I quickly changed the code to:

$addHandler(myElement, “mousedown”, myHandler);

and everything started to work wonderfully.

At least I’ve learned something new, that the eventName passed to the $addHandler function should not contain the “on” prefix. I also re-learned again that I should always RTFM, even the fine prints in the “Remarks” section.

I had a bit of an Apache mix up today causing various feed readers/aggregators to show/aggregate some of my posts from my personal blog.

It seems I’ve accidentally screwed up my virtual hosts configuration and caused everything to be show as my personal blog. My apologizes for everyone.

But, if you do find my personal blog interesting you are more than welcome to subscribe 🙂