Well, I finally have the remaining issues that I had with my dasBlog installation fixed - or at least mostly so. Of course, now I see that there is a new build out on CodePlex (mostly bug fixes) but I'm not going to bother with it at this point in time.

Still, in digging around in dasBlog, I've found a couple of things that I stumbled over that are (I feel) are issues. I'm not sure that I'd put them in a bugs per se as they don't break the application, but I do thing that they oughta be fixed. Don't get me wrong - dasBlog is a great blogging tool and pretty darn solid. I don't know if they've been fixed in the current release, but I'm gonna log them up there as well.  Both of these are in

• Exceptions for flow control: This is is newtelligence.dasBlog.Runtime.LoggingDataServiceXml::LoggingDataService.Xml. This method appears to be using exception handling for flow control. Here's what's going on: when you load up the logs for a particular day, it goes to get those services from the file system (the default location is under the Logs folder of the root web). First it checks for archived (zipped) files ... and it does this right by checking for file existence. But ... when it looks for files in the Xml format, it doesn't check for the file existence. It just tries to open it, assuming that the file is there. Well, it may not be ... if the date is in the future or there are no logs for it (i.e. you tried to get the logs for pre-dasBlog), it throws an FileNotFoundException. This is then caught by the generic application exception handler. The simple solution is to use a wrap the using block for the new StreamReader with an if block that checks File.Exists(path).
• newtelligence.dasBlog.Runtime.LoggingDataServiceXml.ArchiveLogFiles: This is using AppPool.QueueUserWorkItem for multi-threading. This isn't really ideal for multi-threading in a web application ... you really should use the page async model. Though ... I'm scratching my head as to the correct way to implement this. This is called by the WriteEvent method of the LoggingDataService ... so it's not something that you can really put into a PageAsyncTask. Doing so would, it seems, involved a change to the admin pages to call this on demand from the admin UI. That, however, may also violate the source independence of the archive provider.

These aren't, by any stretch of the imagination, show stoppers. The exception handling one, though, really gets under my skin. Exception handling for flow control - and I'm calling it that, though really to do so is something of a stretch because it's only caught by the application's generic handler - is pretty bad mojo. And it's expensive. Much more expensive than a simple check. Just do an MSN Search for Exception Flow Control. It's all over and it's not language-specific. Fortunately, in this case, the fix is a simple one.

I do have a little beef too, though and that's with the reporting. Daily reports into your email are good - don't get me wrong - but it'd be nice to see aggregated reports across a week, a month or more.

And yes, before you ask, I've also applied to join the team so that I can fix things and add new stuff rather than sitting here and complaining about it.

I promised that I'd make the materials from my talk at the Austin Code Camp available for download. I've finally gotten it compressed and uploaded. It's 111 MB so be forewarned. Since I used WinRar (and that's not as ubiquitous as zip formats), I've made is a self-extracting archive. You'll need Visual Studio 2008 Team Edition for Software Developers (at least) to read all of the performance results. But I do have an Excel spreadsheet with the pertinent data.

As you can see, I've updated the look of this here little blog o' mine. I know it's not quite perfect and I'm sure some of y'all out there would do a much better job of making it pretty, but I think it's not too shabby for a graphically-challenged programmer-type such as myself. It's still using dasBlog, of course, and I still have a bit to do before it's completely finished ... I want to add some additional graphical decorations and need to do some work on the admin stuff ... but it's mostly there. I also need to add some more blogs to the blog roll.

I would like to thank a couple of folks for inspiration:

• Ben Scheirman: His presentation at the Austin Code Camp seemed to make me think that I could actually pull this off using CSS only for the layout. And also provide some tips. Additionally, I examined (in detail) the layout and CSS for www.dasblog.info, which he designed. So ... after some 10 years or so of using tables for layout, I'm finally moving past them.
• Joshua Flanagan: I pretty much took the <fieldset> idea for the individual blog items from his site design.
• John Forsythe: I started with his DirectionalRedux theme for dasBlog. It is somewhat unrecognizable now, but it did provide the base. And a lot of it really didn't change much.
• The whole dasBlog team, of course!

Some notes on the trials and tribulations ...

You saw, I'm sure, the issue that I came across if my previous entry. If not, well, go check it out then!

That said, the templating engine for dasBlog, while powerful was, IMHO, somewhat difficult to work with ... no editor design support. While I do use HTML view for my markup, I still like the designer views. That's pretty minor though, considering the functionality and flexibility provided by dasBlog.

Now, I am using Framework 3.5 for the AJAX support and the AJAX Control Toolkit. However, I found that enabling the search highlighting feature of dasBlog blew that up (at least that's what it looked like). So I turned it off. While it was somewhat difficult to figure out, it's really not that big of a deal.

Overall, most of the real trials and tribulations were all my fault ... I'm just graphically challenged and that's that. Ensuring that the site looked OK in both IE and FireFox was fun ... each one has it's own little quirks ... but I'm sure that's not a surprise to any of you. There will be additional updates in the future but, for now, I'm going to start Memorial Day weekend by blowing something up. Virtually, of course! ;-)

I've never seen this error message before. Saw it yesterday as I was re-theming dasBlog for this blog o' mine (coming soon ... I'm almost done).  I was working on adding some extenders from the Ajax Control Toolkit (if you not seen this - and I'd be surprised if you haven't - it's a collection of super-cool extenders for ASP.NET Ajax) and this fun little message came up.

Here's what I was doing ... I have a hierarchical list that I'm adding in the side menu. It'll have the typical menu header, but to conserve space, I'm using the Collapsible Panel Extender to allow certain child sections to be expanded and collapsed. I first tried to do this with Data Binding (the easy way out), but the whole TargetControlID thing didn't work too well in that scenario. I'm sure that, with enough contortions, I could make it work but that'd defeat the entire purpose. So ... rather than do that, I just added all of the controls in code. Tedious, but not very difficult. Then, when I ran this, I got the message above - "Operation could destabilize the runtime."

"Hmmm", I thought to myself, "why on earth would this destabilize the runtime." Well ... not quite like that ... there were some additional words in there that aren't really appropriate for this blog. It had already been a long, already frustrating day (for other reasons), my brain hurt and I was now pretty frustrated. If I had hair, I would have been pulling it out (a very good reason to shave your head, by the way). I tried to remove the lines that the stack trace was pointing to, only to continue to get the error.

And yet, there was a certain pride, I suppose. Must be doing something pretty hardcore to destabilize the runtime, eh?

Actually, that wasn't the case. Of course, it would have been quicker and less frustrating had I been more methodical and logical about debugging the problem rather than just commenting a line of code and then refreshing the page in IE. But it's funny the dumb things that one does (at times) when the frustration level goes over a certain point. Well, not really funny at the time.

When I finally did get methodical about it, I found that the error really wasn't at the line in the stack trace. Why the stack trace pointed to the wrong line is a mystery, but one that will, for the time being, remain so as I really don't care to figure out why - it doesn't matter anyway. When I finally went to debug mode (attaching the VS debugger), the error occurred as soon as it entered the function that was building the controls ... the stack trace in the ASP.NET error page was pointing to one of the lines in this method, several lines into the method. Even more interesting was the exception detail: "Make sure your application is not loading two conflicting versions of a class library." Huh? How on earth is this happening? And what library is being loaded more than once with a different version? These mysteries, unlike the stack trace issue, did matter and they mattered quite a bit.

Now, keep in mind that dasBlog was done with ASP.NET 2.0 and Framework 2.0. I had upgraded it to Framework 3.5.

I dug around in my web.config file trying to see what was going on ... but there was nothing in the references that pointed to the issue. Still curious, I fired up the Fusion Log Viewer to get a better idea of what libraries were being loaded.

It turned out that the Ajax Control Toolkit was, for some reason, trying to load the original version of ASP.NET Ajax. I'm not sure why ... I had the 3.5 version of the toolkit referenced ... but it was. And the Ajax library 3.5 was already loaded - it was referenced in my web.config file specifically by version. Hence the error.

Further digging around in the web.config, I found that many (well, almost all) of the web.config settings for ASP.NET Ajax library weren't in there. This, naturally, presented something of a problem. So I methodically added them in and presto! ... it all worked. It turns out that the critical setting was the assembly redirection for ASP.NET Ajax 1.x. It wasn't in there ... so the 1.x library wasn't being replaced with the 3.5 version.

One note: this was the version of the toolkit 3.0.11119.0, released in November '07. The current version of the toolkit is 3.0.20229. I've not upgraded to that yet (I will before it's released) so that may fix the issue. I did look in the source for 3.0.11119.0 and saw that it does reference the 3.5 version of Ajax ... so exactly what's going on, I don't know. Still, regardless of any of this, the assembly redirection element in the web.config really needs to be there anyway.

Well ... something like that but not exactly. There's a new user group starting up here in Houston that's going to focus on gaming ... not playing games, but creating them. They are going to focus on the tools, techniques and tips that the average developer needs to create games for XBox or Windows using the XNA toolkit.  It's called the Houston Gaming and Media User Group (HGMUG); you can check out their web site at www.hgmug.org or out on CodeZone at https://www.codezone.com/UGEventView.CodezoneCom?EventID=5160.   There's also a Facebook Group that you can join (if you are on Facebook, that is) at http://www.facebook.com/pages/Houston-TX/Houston-Gaming-and-Media-User-Group/16844147291. They'll be meeting for the first time this coming Thursday (5/22/2008) at the Houston Microsoft office where they'll get started with some history, current theory and some best practices for game development in addition to an overview of the XNA toolkit. And, yes, there will be a death match to cap off the evening (it wouldn't be a gaming user group without it, now would it??).

Hope to see ya there!