As an update to a previous entry, Peter Golde has updated the PowerCollections library to be compatible with the final release of Whidbey.  Yeah! I can go back to using the official release!

Well, we had the Turkey Bowl this weekend, an annual flag football game between the juniors and seniors in our church youth group.  Since I teach the 11th grade Sunday School, I was the junior coach. We ended up losing, though through no fault of poor playing.  A good time was had by everyone.

In my role as coach, I felt the need to look more official, so I used my XBox headset to accomplish that.  Check out the whole photoset.

We made a discovery today that the most recent release (1.0) of the PowerCollections library is not compatible with the .NET 2.0 RTM.  This is because of the changes in System.Collections.Generic.KeyValuePair<TKey,TValue> to make it immutable. (The change was actually in a release candidate before the final release.  Basically the public Key and Value fields were abstracted via readonly properties.) A few of the PowerCollections classes make use of the formerly-exposed fields to set or modify the key and value.

So, I made the necessary changes to the project so that we could continue to use it.  But, I'm surprised that Peter Golde, who owns the project, has not at least acknowledged there is a problem and provided an updated version.  I'm tempted to post my changes because there seems to be alot of people who are complaining about it in comments and the forums. But I wouldn't want to cause a "fork" in the project at all, especially for such a trivial thing.  I know there are several other things that ought to be changed to accomodate changes in the release, like arrays properly implementing generic IList.  There is a specific workaround for the issue in PowerCollections.

[UPDATE:] This has been fixed officially!

Another geeky post.

We built our own query system several years ago.  It used the concept of "query by example" with templates that were interpreted into SQL.  You could generate the equivalent of an "IN" clause by assigning something that implemented System.Collections.ICollection to a template property.  Recently, with the introduction of generics and the generic collections, we decided to relax that contract to IEnumerable since that's really the least common denominator of all collections.  This produced some hilarious results.  As you can imagine, anywhere where we were using strings to specify template values, they were being interpreted as collections of characters.  This manifested itself mostly by having queries return nothing, since our system properly handled Chars and treated them as strings.

But, this reminded me of a similar incident a few years ago that involved a framework that rendered objects as comma-separated values. So, instead of:

Mark, Miller

You'd get:

M, a, r, k, M, i, l, l, e, r

I thought since I had been bitten twice, I would write it down.  I usually don't forget stuff I take the time to write down.

So, the moral of the story: Remember that even though System.String implements System.Collections.IEnumerable (and now System.Collections.Generic.IEnumerable<System.Char>), you usually don't want to treat it as a collection.  You may need to special-case it.

Anyone else think of another type like this?

I ran into a nasty performance problem recently.  It involved some AJAXy type dynamic requests.  The problem was that two requests always seemed to be occuring serially rather than taking advantage of the wonders of a multithreaded server and running in parallel.  After much spelunking and debugging, it suddenly occurred to me that the handlers were marked with IRequiresSessionsState to pull a trivial piece of information out of the session.

You may not be aware, but accessing the session usually results in an exclusive lock.  Normally, this isn't a problem since users very seldomly open multiple windows or send simulataneous requests, and sessions usually represent unique users.  But fire off two simultaneous requests, and they will be processed serially.

But, if you mark your page as being "ReadOnly" (or disabled) via the EnableSessionState attribute of the @Page directive (or IReadOnlySessionState for IHttpHandlers), you'll help yourself out.  ReadOnly will get a reader lock on the state, allowing multiple readers access, while disabled (via "false") will not lock at all.  In addition, if you're running your session state out-of-process, disabled will keep you from incuring a hit from the db or other store access.

Just an interesting bit of information that thought would be useful.

We had what I deem to be the most beautiful weekend all year.  It was very cool out (70-80 in the afternoon) with a great breeze.  We took the opportunity to air out the house, which was nice because I was back in the bathroom stinking it up...with landscape block adhesive, that is.  I was building the step that surrounds the new tub, which is raised about 8 inches off the floor.  This is primarily to allow for the plumbing retrofitting, but has a nice look to it as well.  It's been a very long project, but is coming to a close finally.  All that's left to do is tile and paint.

For those photo-nazis out there, I have lots of pictures. I just haven't had a chance to get my new photo pipeline up.  I've made some enhancements and I want to make sure they are all working before I throw a few hundred pictures at it from the last several months.

Back on the subject of the beautiful weekend, we had practice for our church's annual juniors vs. seniors football game.  I'm coaching the juniors, so you can bet there will be some crazy plays as I'm not an "American football" person.  Anyway, some of my helpers and I were just providing some generic defense for them and my legs weren't prepared for that kind of sprinting and stopping, and my hamstrings are incredibly sore today.  But it was alot of fun.

My brother, Andrew, and his wife, Sara, have started a blog.  He's piggybacking off of my site for now.  Here's his inaugural post.  Let's hope we hear more from him.

Here's the logic response to Peter's experimenting:

[UPDATE] Since I've gotten some favorable response to this post, both in the comments and in email, I thought I would give some special, behind-the-scenes information

When I saw Peter's pictures, I immediately thought of the series (1,2) of photoshop trickery I did a while back. Look familiar?

Now, if you'll notice, in Peter's original, he is looking straight at the camera.  So, I had to fix the eyes and distort the nose so he's looking over at Jenkies, who is also obviously added to the scene.