The .NET framework library is a fairly pleasant place to work. A well documented, rationally structured, and easy to navigate API that always seems to have the right thing when I need it. Culturally sensitive pluralization? Yep. Image rotation? Yep. Oh, you wanted to create your own LINQ provider? OK then. Happy days.
Sometimes, though, you come across little oddities that make you groan.
Consider the following – you want to load all files in a directory that end in .doc (typically Microsoft Word files). Should be easy, right? Let’s fire up LINQPad and find out:
Well, that doesn’t look correct at all? I asked for .doc files, but got two more files as well. I guess it’s just expanding my search then, and using an implicit wildcard at the end? If so, I should be able to prove this by searching for .docx files, and only get two files back now.
Wait, what? The .docxx file that came back in the first results, has now not been returned. What could be going on? Well, as a matter of fact, here’s a little clue which might resonate with slightly older readers (if indeed, the post title has not yet given it away):
The clue is, of course, in the MSDN documentation for the method call. The method checks both file names – the current, modern one, and the legacy one that is maintained for backwards compatibility with 16 bit programs, written for Windows 3 or DOS. What a fantastic boon for those continuing to use older apps; and what a curse for the rest of us!
Then again, you can upgrade Windows 1 to Windows 7…
Recent Comments