No offence meant please…

The local bar was so sure that its bartender was the strongest man around that they offered a $1000 bet. The bartender would squeeze a lemon until all the juice ran into a glass, and hand the lemon to a patron. Anyone who could squeeze one more drop of juice out would win the money. Many people like weightlifters, wrestlers, body builders, etc had tried over time, but nobody could do it.

One day this scrawny little man came in, wearing thick glasses and a safari suit, and said in a tiny, squeaky voice, “I’d like to try the bet.” After the laughter had died down, the bartender said OK, grabbed a lemon, and squeezed away.
Then he handed the wrinkled remains of the rind to the little man.

But the crowd’s laughter turned to total silence as the man clenched his fist around the lemon and 5-6 drops fell into the glass. As the crowd cheered, the bartender paid the $1000, and asked the little man, “What do you do for a living? Are you a lumberjack, a weightlifter, or what?” “No,” replied the man. “I work as project manager for the IT Department”.

More optimized and condensed ViewState is one of the major improvements in ASP.NET 2.0. Remember those days, you have placed a paginated DataGrid on page only to discover later that huge ViewState reluctantly generated inside your page. Now in ASP.NET 2.0, you must have noticed smaller size of ViewState compare to the previous version. How about moving further to squeeze payload of page, by compressing ViewState before rendering it to page?

Here is the small tutorial on compressing ViewState in ASP.NET 2.0:
Compressing ASP.NET 2.0 ViewState

By compressing ViewState, as mentioned in test case, you can squeeze the size ViewState from 43.3 kb to 3.50 kb. Now this is the major performance improvement with no major modification in your application. All you have to do is to change base class of pages in question (like page with DataGrid, or page with lots of dynamic controls etc.) from System.Web.UI.Page to PageViewStateZip, and you are done.

We always log all kind of exceptions raise at server side to keep track of all those bugs. But what about JavaScript errors occurred at client side? I think we are simply loosing great amount of debugging information by not logging these JavaScript errors, which IMO can surly help developers to cut replicating and testing effort.

Here is the superb library which can log all JavaScript errors occurred at client side to event log.

Links:
JavaScript Logger: Logging JavaScript Errors To ASP.NET
Download (DLL & Source Code): ClientLogger.ZIP

The JavaScript exception logger is having three segments:
1. Script at client side which will catch Javascript exception using onerror event of window and notify server using AJAX mechanism. So there will be no PostBack for passing exception to server.
2. HttpHandler on server which will receives this exception notification and passes it to EventLogger.
3. EventLogger which converts passed exception into string and logs it in the EventLog

Exception information which logged into EventLog:
1. Actual JavaScript error message
2. JavaScript URL
3. Line number of the script where exception has been occurred.
4. Page URL
5. User Agent
6. Session ID

You can further enhance ClientLoggerHandler class, if you want to log any other browser/OS specific information. With that, as most developers always prefer to log exception in database, you can modify WebJavaScriptErrorEvent accordingly.

To enable JavaScript logging, you just need to drop a Logger control on the page (or on Master Page) and register HttpHandler.

Note: This library has been developed using ASP.NET 2.0, but I am sure it can be easily used in ASP.NET 1.1 as well with very small modification.

Happy Logging!!