I’ve not heard much about ASP.NET 4.0 yet. I don’t know if that’s because there’s not much information out there yet, or (more likely) because I haven’t been looking. We’re still very much in 2.0 land at work, so there’s not too much point getting excited about v.next features. But today I stumbled across a post on a post on an official asp.net blog called ASP.NET 4.0 ClientID Overview that details the support 4.0 will have for controlling the client-side IDs generated by server controls. Those familiar with ASP.NET will know that in current versions, all server controls that have specified IDs (thus enabling them to accessed from the code behind) generate corresponding client-side IDs containing their full naming-container hierarchy. This guarantees their uniqueness, but often means they’re very long and push up the page weight. It looks like ASP.NET 4.0 will do some work in this area to give developers more control over what IDs are generated and when, on a per control basis. Sounds pretty cool, roll-on 2015 or whenever that I can actually use this stuff in production!

Phil Haack has posted a couple of blog posts recently on named formatting in .NET. The basic idea is, instead of the usual numbered placeholders in a String.Format string like "Hello {0}, you have {1} unread messages", you have the name of properties, which are then reflected from some source object, e.g. "Hello {Name}, you have {UnreadCount} unread messages". He posted his own implementation, and a solution file containing unit-tests and a performance comparison with some alternative implementations. These posts in turn prompted a few responses from people who produced their own, even swifter implementations. So obviously, I had to have a go myself. I went for a simple, ugly, but fast approach, and at the time of writing I believe mine is the fastest (by a couple of hundredths of a second) except for one that uses some wacky Linq stuff to pre-compile property-accessing lambdas and assemble them for a particular format string. The code for mine can be found here. It’s not pretty, and I certainly wouldn’t write code like this for anything serious, but it was fun to do.

Lets All Play Doom

As part of my commitment to actually get some content on this site, I’ve been going through my archives of material and old hard-disk contents to find anything worth salvaging. For the most part it’s a parade of embarrassing E/N sites, fragmented IRC logs and stupid animated gifs. I did find something I thought was quite fun though, it’s the spoof article I wrote way back for a (fictional) site called LetsAllPlayDoom.com. I think I created it in around 2000, shortly after Doom 3 had been announced by Id Software. The premise was that it was an article from the future, March 2005 to be precise, by a Doom 3 fansite, investigating the rumours of a predecessor game.

letsallplaydoom.com: Doom – A Retrospective Glance

Reading it back, it’s a bit hit or miss, but better than most stuff I wrote back then (and probably nowadays as well). It feels a little curtailed, I never really exploited the idea properly as there’s very little that actually focuses on Doom’s gameplay itself, instead most of the article is about the history of Id and a rather labored pun on the word “prodigy”. I did get to use a joke about the “burn all gifs” campaign turning militant in a too-literal fashion, which I’d been saving for a while and I still think is quite an amusing image.

Fun bonus fact: Some time later I considered writing a much expanded version of this article as a spoof of the book Masters of Doom, to be called “Barons of Hell: How a Couple of Nerds Got Rich and Bought Some Fast Cars”. It was to feature copious Romero trolling. I wrote a few pages, but decided to put it on hold until I actually got a copy of Masters of Doom to read through. In the end, I never did though. Fascinating, eh?

Firefox is eating my cookies

I recently suffered a problem where Firefox began forgetting all my account authentications and what-not each time I restarted the computer. Investigating further, I discovered all my profile’s cookies were being wiped every time I exited the browser. Searching bugzilla turned up a few open bugs where people described having the same problem, but none of the them had fixes or answers beyond “check your settings” and “delete Firefox, trash your profiles, re-install”. I eventually found the answer in some mozillazine forum thread, which I thought I’d post here, in the hope that it may help any poor soul Googling the issue.

The problem is apparently caused by corruption of the SQLite database file used to store cookies for you browser profile. The fix is (or was in my case) to delete the cookies.sqlite file completely. Under Windows Vista, the file is located at: Users[account-name]AppDataRoamingMozillaFirefoxProfiles[random].defaultcookies.sqlite

When you next run Firefox, it should recreate the cookies.sqlite file, this time free of whatever evil corruption had infected it. Exactly what causes the corruption in the first place isn’t clear. People in the mozillazine thread where I found this answer claimed a poorly written add-on or plug-in is the likely culprit. The only add-ons I had installed at the time were Firebug and the Microsoft .NET Framework assistant. I have a bunch of plug-ins, but only the normal stuff like Java, Flash, Acrobat, etc. I guess it’s just one of those things. Anyway, I hope this helps someone somewhere.