Advanced .NET Debugging

Typed DataSets are a type safe wrapper around a DataSet which mirrors your database structure. It was created to make sure that the code accessing the database is type safe and any changes in the database structure that changes tables, columns or column types will be caught at compilation time rather than runtime.

If you have a big typed dataset that contains a lot of tables, columns and relations it might be quite expensive to create it in terms of memory and time.

The main reason that creating a big typed dataset is expensive is due to the fact that all of the meta data that is contained within the typed data sets (tables, columns, relations) is created when you create a typed dataset even if eventually all you’ll use it for is to retrieve data from a single table.

I can speculate that the reason all of the typed dataset meta data is created during the instantiation of the typed dataset is due to the fact that it inherits from a generic DataSet and accessing the meta data (tables, columns) can also be done in a non type safe manner (i.e. access the Tables collection and/or Columns collection of a table).

If you are using a typed dataset (or dataset in general) you might be interested in the following tips:

• If you have a big typed dataset, avoid  creating it too many times in the application. This is specifically painful for web applications where each request might create the dataset. You can use a generic DataSet instead, but this might lead to bugs due to database changes and the fact that you’ll only be able to find these bugs during runtime rather than compilation time (which basically misses the whole point of using a typed dataset in the first place).
• DataSets (typed datasets included) inherits from the MarshalByValueComponent class. That class implements IDisposable which means DataSets will actually be garbage collected after finalization (you can read more about finalization and the finalizer thread here). To make sure datasets are collected more often and are not hagging around waiting for finalization make sure you call the “Dispose” method of the dataset (or typed dataset) or use the “Using” clause which will call “Dispose” for you at the end of the code block.
• Don’t use DataSets at all Consider using a different data access layer with a different approach such as the one used in the SubSonic project.

I guess it would be rather trivial creating a typed dataset that is lazy in nature which creates the meta data objects only when they are accessed for the first time. That would reduce the memory footprint of a large typed dataset but will make the computation used to create these objects a little less predictable. If you are up to it or already did a lazy typed dataset ping me through the contact form

If you mix and match 32 bit machines/processes with 64 bit machines/processes in an ASP.NET load balanced environment and you are using the AJAXControlToolkit ToolkitScriptManager class you might end up with the following error:

Message: Assembly “AjaxControlToolkit, Version=1.0.10920.32880, Culture=neutral, PublicKeyToken=28f01b0e84b6d53e” does not contain a script with hash code “9ea3f0e2″.
Stack trace: at AjaxControlToolkit.ToolkitScriptManager.DeserializeScriptEntries(String serializedScriptEntries, Boolean loaded)

at AjaxControlToolkit.ToolkitScriptManager.OnLoad(EventArgs e)
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

The reason is that the request being sent to retrieve the combined javascripts of the control used in the page contains a hash code that is used internally. That hash code is being generated from the script’s name using the default string.GetHashCode function which returns different values for 32 bit and 64 bit processes.

If your 64 bit process creates the javascript include call which contains the 64 bit hash code and the request will eventually reach the 32 bit process/machine you will get this error since the hash value will not be found internally and vice versa.

There is an open issue about this in CodePlex since late January but as of the time of this post, the latest source version in CodePlex doesn’t have a fix for this.

Sometimes in ASP.NET when you are trying to access a certain page you might get the following error:

External component has thrown an exception

In some other situations in .NET you might get this error as well (not directly related to ASP.NET, but sometimes to Interoping code or COM code), but this is beyond the scope of this post.

In the cases that I’ve stumbled upon, the reason is usually related to on-the-fly compilations ASP.NET performs when first accessing a certain page on an application.

The main problem with this exception that it is less than informative . The only way of actually figuring out what is wrong (if this is indeed a case related to compilation error like I’m talking about) is to dig deep using WinDbg.

Luckily, every compilation that runs inside ASP.NET uses an API that upon encountering an error will create an object in the heap called CompilerError.

To debug this issue perform the following steps:

1. Attach WinDbg to the ASP.NET worker process (w3wp.exe in Windows 2003, aspnet_wp.exe in Windows XP/2000)
2. Make sure you have CLR exceptions enabled (see this previous post about how to enable CLR exceptions in WinDbg).
3. Try to access the page that is not working, it should throw an exception and WinDbg should break in.
4. Run the following command:
   

   !dumpheap -type CompilerError

   This should produce a list of all CompilerError objects which should allow us to inspect them and see the exact compilation error.

5. Now dump each of the objects using the following command:
   

   !dumpobject 0xXXXX

   Where 0xXXXX is the address of the objects listed in the list you got from the !dumpheap command.

6. At that point you should see the CompilerError object itself and you can dump its errorMessageText member (it’s address is near its name) using !dumpobject which should show you the exact compilation error.

In my case, the problem was that in the web.config file under the <compilation> / <assemblies> element there was no reference to one of the AJAX.NET assemblies (System.Web.Extensions) which caused the page to fail during on-the-fly compilation.

Do remember that this exception sometimes has nothing to do with compilation. If you don’t have any object of type CompilerError or there are a few but they make no sense in regards to the page you are accessing it might be something else.

The ASP.NET Repeater control is a very useful patten that minimizes code and allows you to use templates to represent repetitive data.

All of you are probably familiar with it and use it quite often.

Yesterday I had a big fight with the repeater control, and since most of the Internet (actually search engines for that matter) is filled with lots of data about the Repeater control and how to use it, I couldn’t find the answer I was looking for.

Apparently it was staring me right in the face.

The problem was that I needed to display a list of words with a comma separator and they should have looked like this:

word a, word b, word c, word d

but what I got was this:

word a , word b , word c , word d

An additional and unwanted extra space before the comma.

That code that I used in the ASPX file was this:

<asp:Repeater>

<ItemTemplate>

<% #Eval(”Text”) %>

</ItemTemplate>

<SeparatorTemplate>, </SeparatorTemplate>

</asp:Repeater>

All seems well, right? there is no space before the comma in the separator template, but there was when the whole thing was rendered.

The fix was quite stupid (and is quite fragile):

<asp:Repeater>

<ItemTemplate>

<% #Eval(”Text”) %></ItemTemplate>

<SeparatorTemplate>, </SeparatorTemplate>

</asp:Repeater>

The extra enter which placed the </ItemTemplate> element in a new line was the cause of this problem. That new line was translated in this case into a single space which made everything look weird.

It seem that the Repeater control (and possibly other template based ASP.NET controls) are sensitive to the ASPX formatting. They are not trimming the edges of content that resides inside the template ASPX element, thus making them susceptible for formatting weirdness.

The worst problem of all is that when you use Visual Studio’s auto formating (Ctrl-E, Ctrl-D by default, if I’m not mistaken) it will ruin the layout and you might end up with a Repeater that has an extra space even if you didn’t want it.

I can understand why the edges were not trimmed, so that you can and should be able to enter white spaces as part of your template, but Visual Studio itself when formatting a document to be more clearly read will mess things up and that is the true problem.

While this is not a “real” advanced .NET debugging issue and I didn’t use any cool tools to figure it out it annoying nonetheless

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

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.

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.

In my previous post about problems with wrongful escaping of the query part in the uri in Request.QueryString, I’ve received a comment from a reader named DuncanS saying that he encountered a similar behavior with the Uri class.

It seems Uri.ToString() function will perform unnecessary unescaping of the different parts of the Url that were escaped (like the query part) to be unescaped.

His solution to the problem is to use Uri.AbosluteUri instead which does not exhibit this behavior.

Thanks for the tip Duncan!

“Sys.WebForms.PageRequestManagerParserErrorException: The message received from the server could not be parsed. Common causes for this error are when the response is modified by calls to Response.Write(), response filters, HttpModules, or server trace is enabled.”

Have you ever got this kind of error when you are doing an Async postback using AJAX.NET (starting from Beta 2 if I’m not mistaken and going all the way to the current RC1 - at least at the time of writing this post) ?

It seems the newer versions of AJAX.NET really hates having “Response.Write” being called while doing an Async postback. It changes the response a bit causing it a hard time extracting the changed values and updating the changes using JavaScript on the client side.

If you get this error go through your page and all the controls in it (including controls within controls) and make sure you don’t have a “Response.Write” in the markup page.

Having “Response.Write” in the code behind in an event that is fired on an Async postback like Page_Load, Page_Render or the handler that handles that exact event can cause the same problem.

If you must use “Response.Write” you can get a similar solution by using a Label control and update it instead of using “Response.Write“.

If you use “Response.Write” in markup pages (ASPX or ASCX) replace them with either the “=” syntax (<% = MyProperty %>) or use the same solution mentioned above, adding a Label control and updating it in the code behind.

I’ve got a request from a reader, JasonL, to post the function I’ve written to overcome the query string problem that I’ve talked about in the previous post.

You can take a look at my solution here.

My implementation is to take the query part of the current URL, split it and only then perform URL decode on the values (only) of each parameter.

I know that some of you will probably implement the function’s prototype a bit differently by passing the URL to it instead of the function extracting the URL directly from the current request, but to make things simpler that the route I’ve chosen.

The main “problem” with my implementation is that I use a SortedDictionary (the generic one) which will not return null when a key does not exists, instead, it will throw an exception (so be sure to use the ContainsKey function).

I probably did that mainly from a lazy point of view and I just love generics

Anyhow, enjoy.