ASP.NET

Review: Beginning Ajax with ASP.NET

Tim Murphy — Thu, 29 Mar 2007 07:27:00 GMT

First let me say thanks to Craig Shoemaker for sending me a copy of this book. Yes, I know it has been a while since it came out, but I just finally got around to going through it. In that time Craig has been working on another book and Microsoft has renamed Atlas to ASP.NET Ajax.

Craig, Wally, Paul and Scott packed this text with gems, not only on Ajax, but also the technologies that it grew up from.

The book covers how we got to this point. They start all the way back with JavaScript and the DOM and go right through XMLHTTPRequest and JSON.

The topics contained are a broad swipe at Ajax. This 400 page book addresses the Ajax-like features of ASP.NET 2.0 and how they work. It then goes on to focus on the Ajax.NET Professional Library and then gives a brief taste of five other Ajax frameworks. The final Ajax technology addressed it Atlas.

The features I liked most about the book are that there are lots of code samples and explanations of how things work. There are some excellent diagrams showing event lifecycles. The final chapter is one of the best features since it discusses debugging Ajax and its client side Javascript.

The .NET and architecture communities owe this group a lot. Not only for this book, but for all the wisdom that flows from their blogs, podcasts and speaking at events. These guys did their homework and worked through ever changing tools to bring us these pearls. Thanks guys.

ASP.NET Web Application Project Released

Tim Murphy — Tue, 09 May 2006 15:37:00 GMT

For those who are missing the ability to treat your ASP.NET applications in VS2005 as projects rather than individual files this release from Microsoft is for you. If you want all the details and then some check out Scott Guthrie's post.

Why Performance and Scalable is Required Reading

Tim Murphy — Thu, 04 May 2006 16:12:00 GMT

We are in the middle of addressing some production issues at my current client. One of them involves an ASP.NET application which is slow to respond at times and other times does not seem to respond at all. The fun part is that there is nothing from the application side which is giving us a clue as to what is going on. This has been going on for a while and people are starting to get frustrated, so it was decided to call the experts from Microsoft.

So we start having conference calls and the MS representatives start asking for information on our servers so that they can diagnose the problem. When they were sent the machine.config files there was a pause on the other end of the phone. Then they asked a question which in essence was why are the settings still as they came from the factory.

Now in larger companies roles tend to be segregated. For the most part developers can not see what is on the servers, much less change them. This being the case you tend to assume that the administrators know their job and how to optimally setup a machine. Evidently not!

This brings me to the point. The Patterns and Practices group produced a rather large tome some time ago titled “Improving .NET Application Performance and Scalability”. When it was originally published it was 1108 pages (good bed time reading). Now most .NET development teams know about P&P and we have been using the development suggestions from this document for some time. I don't think it is as well known in the administration community. I believe that Chapter 17 on tuning .NET application performance is a must read for anyone setting up an environment.

No I am not saying that this will fix all problems, or even the ones that we are encountering at my client. I do think that if these best practices are applied to standard machine builds I think all of our live would be just a little easier.

To Transfer Or Not To Transfer, That Is The Questions

Tim Murphy — Thu, 16 Mar 2006 15:58:00 GMT

This is one that bit me the other day and re-enforces the need to think about why you use a certain method. I was doing some testing at the client I am working at and a page suddenly started rendering twice in the same browser window. So what I ended up with was:

My Page

Now how the heck can that happen? I was a victum of my own code. The application's detail page was catching a custom exception type and then using Server.Transfer to go to an overview page. No problem, right?

The problem is that calling Server.Transfer causes a ThreadAbortException in the originating page. After the custom exception was caught and the page was transferred and the new page completed its load the thread abort was caught by the original page looking for any System.Exception errors. Guess what was being performed in this catch. That's right. Transfer to the overview page resulting in the scenario above.

I had never seen this behavior before, but then again, I normally use Redirect instead of Transfer. I have read a number of articles and none of them mention the possibility of this happening. All of them say that the page terminates and transfers to the new page. Evidently this is the case for all situations other than exceptions.

Note: This was written in ASP.NET 1.1