Recently in Future Reference Category

I found another big gotcha in .NET today. When iterating over a Hashtable, you might want to change something within that Hashtable, like say change or clear out a value. Ain't gonna happen, buddy. Nice big runtime exception: Collection was modified; enumeration operation may not execute.

I got it the first time and I slapped my forehead—figuratively, of course, as I'm not in the habit of self-flagellation. So I did what I always do. *sigh* I got clever. I thought that I could obviate the problem by enumerating through the Hashtable.Keys collection and make my changes that-a-way.

Again, no dice. I'm not entirely sure how changing the value of a Hashtable key while looping over a collection of keys is affecting the underlying Hashtable. But I think it has something to do with the CLR iterating over the Keys collection by reference rather than by value.

The answer, after some Googling, is to split the operation into two phases: storing the keys to be changed in another collection and then looping over that second store to actually modify the values or do what-have-you. It's decidedly not as elegant as say creating an isolating enumeration class, but I've got work to do.

I've wasted far too much time on this issue, so I'll make an entry for future frustrated Google searchers. You're welcome.

If you need to see if a particular Type object implements a particular interface, it's clear that the method IsAssignableFrom is the proper choice. But the damn thing wouldn't work. is certainly what I was looking for. Then I found Scott Hanselman's entry on the subject and it became obvious that I was reversing the members.

Assembly library = Assembly.LoadFrom(pathToLibrary);
Type[] allTypes = library.GetTypes();
foreach (Type type in allTypes)
{
if (typeof(IInterfaceToImplement).IsAssignableFrom(type))
{
doYourThing(type);
}
}

Previously, I was doing if (type.IsAssignableFrom(typeof(IInterfaceToImplement)) and it just wasn't doing it's thing.

This is going to seem like yesterday's news to my fellow Mac OS X and Unix readers, but I just got something working today that is pretty impressive in the Windows command prompt.

I love this Windows version of "grep"—I install it on every server and desktop I interact with. It's super fast, very similar to the Unix version, and I've never had a single problem with it.

I was trying to use its output as input for another command. This is called "command redirection" in the Windows world and "piping" everywhere else. Sadly, the documentation on the Web about this feature of Windows is sparse. I can see why: Windows executes both commands simultaneously and if the receiving command wasn't designed to wait for standard input then it'll just error out. Like the "del" command, for example. Non-Windows users are welcome to snigger quietly now.

Then I found this article. This isn't piping per se, but the idea is the same. Take the output of one command and use it in another. Once I had that, it was a simple for /f "tokens=*" %a in ('grep -l stuffIwantDeleted *.FOO') do del %a. Worked like a dream!

For my future reference, here's an excellent explanation of the String.Format possibilities in C#.