June 2006 - Posts

LogParser

Recently I had a need to examine IIS log files - lots of them - to do some usage analysis. Analog has been my tool of choice, and although it takes a bit of learning, when coupled with the right config settings will display helpful tables, charts and graphs for summary-type information (click for a larger picture):

But when it came time to answer some more directed questions about web site usage, I thought the best way would be to import the IIS log files covering 2 years worth of data into SQL Server, and utilise my existing knowledge of T-SQL. There were some pointers towards using DTS, but it seemed to me that the functionality of hand-coding import routines, allowing for header records in the log files, and coding looping constructs was already taken care of in Microsoft's LogParser.

LogParser allowed me to import the IIS log files with no problems, it cost nothing, and with a bit of help on command-line parameters from Serge van den Oever's blog, I had the table created and the import running in no time (well, it took just over an hour to upload nearly 700 web log files totalling 920MB into my test server, so that's not really "no time"). There's also an unofficial support site at http://www.logparser.com/.

Once uploaded I used ordinary T-SQL to do my queries. Easy.

This may sound like a breathless schoolboy "you won't believe what I've just done" story. But LogParser really is brilliant :-)

Tags: sql server, logparser, IIS, web server

Jimmy Nilsson New Book - ADDDP

Foolishly, unforgivably, when I first read Jimmy Nilsson's excellent book .NET Enterprise Design with Visual Basic .NET and SQL Server 2000 (Amazon) back in August 2003, I did not review it (short review: it was excellent, and I used some of his methods straight away - well worth the read). Now Jimmy has released a new book called Applying Domain-Driven Design and Patterns : With Examples in C# and .NET (Amazon) that also looks great.

Even though I use Visual Basic.NET much more than I use C#, I'm still going to try and get this one.

Tags: domain-driven design, jimmy nilsson, patterns, development

Autocompletion ASP.NET Control

There are many auto-complete/auto-suggest web controls around, and when I needed AJAX functionality to get the data from the server dynamically, in preferably an ASP.NET control, I started using the excellent "Implementing an Ajax.NET-based Lookup Server Control" on CodeProject.

This is a nice control that works in with AJAX.NET and has many configurable properties. Unlike some of the other similar controls I've found, it also supports keyboard selection of the returned matches (using the up and down arrow keys). And, since it uses AJAX.NET, it can take advantage of Session variables (should you need them). All this is packaged into a replacement control for the standard textbox.

Unfortunately it's beyond me to get more than one of these controls working on the same page - doing this would require some serious javascript kung-fu which I do not possess. So, I did some research and eventually settled on SimoneB's ASP.NET wrapper of the script.aculo.us autocompletion control.

SimoneB has done a fine job - using her sample video, I was up and running in a couple of minutes, and I could use multiple controls on the same page. Also, script.aculo.us brings some nice javascript-based animation into the bargain and SimoneB has made it easy to add a "loading" GIF too. Keyboard support is still there, but unfortunately I can't seem to find how to use ASP.NET Session vvariables (no matter, this can be worked around). Although I believe the script.aculo.us control does cache data, it's not quite as configurable as with AJAX.NET.

One other criteria was that the control by quick to implement. I had a limited window which prevented deep research, in-house development or even the possible purchase of a more fully-functioned control.

Some other alternatives that I have not personally used, but look promising, include GoogleSuggestCloneJax, AJAX.NET sample, AutoSuggestBox, capxous ($), CPAN Suggest, EBA: Web ComboBox V3 ($) and BComplete.

Out of all of these controls, BComplete looks interesting because it overcomes the problems of a lot of items being returned by providing a top and bottom scroll section (most of the other controls take the approach that they'll only return up to 10 or so items, so the rest of the matches aren't unviewable off the page). I lessened the impact for my users by matching after they'd typed at least two characters, which makes business sense in my situation.

Overall the new control is far better in my situation than the standard ASP.NET drop-down, to allow users to type and have auto-suggest, as opposed to only being able to select from a list. Also, page size is reduced because all the options don't have to be pre-loaded.

Tags: asp.net, auto-complete, auto-suggest, javascript, ajax

Update June 14th 2006: Ryan Homer has extended and improved the autocomplete control on CodeProject (not looked at, but might be helpful) to allow multiple instances.

Infrequent Validation of viewstate MAC failed Exceptions in ASP.NET 2.0 Site

I've been developing an ASP.NET 2.0 site for a couple of months now (which got released and used by 100+ people, with no major bugs...high five!)

Every so often, I see a strange error message coming through the logs that reads "Validation of viewstate MAC failed". I'm using a GridView control, bound to an ObjectDataSource, with EnableViewState turned off and DataKeyNames. After dropping into "web developer" mode - where I search the web for the answers to my development problems :-) - I found two helpful sites, at Jotekes Blog and the ASP.NET Forums, which addressed the problem.

It seems that in my case, the problem was occuring with pages that took a while to load, where users were clicking on an edit button in the GridView before the page had fully loaded. The error was raised because a hidden form INPUT necessary for ASP.NET's internal workings called "__EVENTVALIDATION" had not yet been rendered (and thus wasn't passed to the edit link).

I implemented the suggestion on Jotekes Blog and disabled event validation, and view state encryption:

<pages enableEventValidation="false" viewStateEncryptionMode ="Never" />

Making this change saved me some bytes in view state and totally removed the hidden "__EVENTVALIDATION" section at the bottom of the page. My understanding is that from a security standpoint, after making these changes, someone could attempt to POST to my page and I wouldn't be able to tell if the POST came from the same page (this is the event validation part). Also, someone could read the view state.

Given my environment - an internal network (intranet) using Windows authentication - I feel that the security implications of disabling encryption on the viewstate are pretty small. I used Fritz Onion's ViewState Decoder to check out what was contained in the viewstate for the GridView, and it was pretty much the ID's for the records, which were needed for edit and delete functionality. I don't believe that knowing a record identifier would be of much help to an insider on our network.

As for the event validation, I can't see much of a problem (although I can see that turning this off in a public-facing website would be a bad idea).

The advantage is that users can click on edit links in the GridView and start editing. The advantage is that users don't see exceptions, when trying to do their jobs.

Hopefully I'm not missing something!

Tags: viewstate, asp.net