Advanced .NET Debugging

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

When working with a complex environment such as the ones being created by most (if not all) AJAX applications nowadays, one needs a set of tools in his/her arsenal to overcome any obstacle.

FireBug, a web development and debugging extension for Firefox is one such tool that you must keep close.

As it site says:

Firebug integrates with Firefox to put a wealth of development tools at your fingertips while you browse. You can edit, debug, and monitor CSS, HTML, and JavaScript live in any web page.

If you are not already using it go quickly, download and start working with it.

There are two major benefits of using FireBug when developing ASP.NET and AJAX.NET application:

1. HTML Inspection - FireBug allows you during runtime and on any site, to inspect how the HTML looks. This includes direct references to the various stylesheets being used an element (including the casecading parts and from which .css file they came from). It also includes the ability to visualize the unvisible styling elements of padding and visualize so that you’ll visually see where the styling problem is as well as change the various style settings on the fly and immediately see the results.
2. JavaScript Debugger - The JavaScript debugger and expression evaluator in FireBug are a lot easier to use and are a lot more powerful than the ones supplied by Internet Explorer combined with Visual Studio (or what is actually Active Scripting Debugging from the happy old COM days ). Visual Studio is a very heavy debugger and sometimes lacks the ability to debug even sites and JavaScript that you just want to know how they work, without having the actual code of the site.

In the early days of AJAX.NET (or should I say in the “Atlas” days), FireBug was my main weapon of understanding the AJAX.NET framework and stepping line by line to understand how to use and work with AJAX.NET.

It’s an invaluable tool in your arsenal and with the usage of AJAX.NET increasing on a daily basis you just have to have it.

At my day job, we started getting a strange compilation error when accessing one of the pages (the ASPX file).

Upon first access to an ASPX file, ASP.NET parses the ASPX file and combines it with the ASPX.cs/ASPX.vb (code behind) to create one single .cs/.vb file, compile it and loads it into the memroy.

The error was quite strange:

The type or namespace name ‘Compatibility’ does not exists in the namespace ‘System.Web.UI’ (are you missing an assembly reference?)

This was just a simple page. Not fancy AJAX code. You can see how it looked when I set customErrors=”true” in the web.config here.

After digging a bit more, I’ve turned on the debug=”true” in the <compilation> tag in the web.config file and got a more details error (look at the screenshot here).

I was not familiar with any System.Web.UI.Compatibility namespace in ASP.NET so I searched throughout the project. I came across this namespace in the web.config file itself in the <system.web> \ <pages> \ <tagMapping>.

This set of configuration tags is added for use with AJAX.NET and it simply says that if you see System.Web.UI.WebControls.CompareValidator replace it with System.Web.UI.Compatibility.CompareValidator that is found at System.Web.Extensions - System.Web.Extensions is one of the AJAX.NET assemblies.

A light bulb flickered above my head and I figured that the problem was in the ASPX compilation.

When you set debug=true in the <compilation> tag in the web.config, the path at the bottom of the error page will actually include the temp .cs/.vb file ASP.NET has created as well as a few .cmd file which are in fact the command line passed to the C#/VB.NET compiler to compile the code.

I checked it out and it seems System.Web.Extensions was missing from the command line.

I’ve added it to the <compilation> \ <assemblies> and it worked.

I still don’t know what is the exact cause of this problem, but I figured having an extra reference in the compilation shouldn’t cause any harm. At least for now.

I had a couple of problems in the transfer with the feed of the new blog (http://dotnetdebug.net/feed/).

It is redirected to the Feed Burner feed and should be working OK now. The auto discovery of the feed should also work (I hope).

Please let me know if there are still problem with it.

Hey all,

Let me welcome you to the new home of Advanced .NET Debugging.

Having a new home and a new address will let me experiment a little bit more with this blog.

If you don’t already know, I have a personal blog, in which I talk about other things not related to .NET debugging (though sometimes it is related to programming and development in general).

I recently got a little bit more involved in identity online. That’s why this blog also has my MicroID WordPress plugin as well as my OpenID Delegation WordPress plugin and will allow you to authenticate yourselves with OpenID to add your comments.

These little things are important to me, being the geek that I am and I hope it will help you, me and the rest of the Internet community.

Anyhow, enjoy and don’t forget to tell your friends

You know I don’t like to be an echo blog, but I couldn’t give up on such a fine piece of code.
This is really one of the things I said to myself “How didn’t I think of that before?”

Mike Stall has a great post and a piece of code that he wrote about using P/Invoke to access unmanaged Windows API code.

He has written a rather generic wrapper that does all the dirty LoadLibrary, GetProcAddress code and you can generically get a function and execute it without thinking twice.
It uses SafeHandles and make all the necessary releases (if you use it correctly) without you having to worry about it.

Check it out (don’t forget to read the disclaimer he wrote there) and have lots of P/Invoke fun.

I bet one of you (or maybe even me if I’ll find some time) can write a code generation utility that will use this code to create a wrapper for most of the unmanaged Windows API code that goes around making it even more type-safe in the sense if not having to pass around strings to get function names and having to deal with a generics deceleration of the function you are using.

Forgive me for a non technical post but apparently I’ve been tagged by Tess which means I probably need to say 5 things about myself. Hmpf…

Oh well, here it goes:

1. I can’t eat tomatoes. I can eat them in the form of ketchup and in the form of a sauce (on Italian food, for example), but I simply can’t bare the thought (or taste) of having a raw live tomato in my mouth (yuck!)
2. I have yet to complete any formal degree from a formal institution what so ever. I’ve finished about 1/3 of a Computer Science degree in the Open University in Israel. I simply figured since I’m already rather proficient in CS I would be better off actually studying something else. I’m still considering Philosophy but haven’t had the time to make it so, mainly because I work full time and the Open University doesn’t have a Philosophy degree (perhaps its time for University 2.0, something that will actually fit people like me ).
3. I learned and/or playing the following musical instruments: Flute, Saxophone (soprano, alto, tenor and Baritone), Guitar (electric, classical, acoustic and bass), Piano (not enough to play Rachmaninoff, but enough to understand the basics and compose music on it), Drums (not too well, but enough to keep a steady beat)
4. I own a Sea Kayak (an Ocean Kayak Scupper Pro) which I’ve been taking off to sea in the summer (I still haven’t gotten a dry swim suite like the divers have to actually kayak in the winter). It looks rather funny on my car’s roof (a Peugeot 206) since the car is 3.8 meters long and the Kayak is 4.5 meters. I’m starting small. My first goal is that in the Summer of 2007 I’ll Kayak from Hertzliya to Tel Aviv and back (around 30km).
5. I’m going to be 26 in 17 days (21st of January) but I’m still being referred to as the Kid (or sometimes Wiz Kid) by my co-workers, mainly because I formally started to work in the industry at the age of 16 and I’m still the youngest person at work.

OK, now I need to find 5 other people I wish to tag. I feel kind of sleazy continuing this blogosphere chain letter like effect, but what the heck. Let’s go with the flow.

I’m hereby tag Alex, Shay, Liron, Eran (not me) and Yossi.