I’m feeling particularly geeky having just re-imaged my laptop’s dev partion. This is what’s running on it so far:

• WinFX Runtime – Sept CTP
• VS 2005 Team Suite Beta 2
• WinFX SDK – Sept CTP
• VS Extensions for WinFX Sept CTP
• VS Extensions for WinWF Sept CTP
• WinFS Beta 1
• DSL Toolkit Sept CTP (I hadn’t realized a new CTP shipped!)
• Guidance Automation Toolkit Tech Preview
• C# and VB LINQ Tech Previews

Not that this is of much use to anyone, but I thought it was cool. Not sure what I’m going to do with all this stuff yet, but I just had to have it all. I guess the stint in marketing didn’t completely wipe out my interest in coding.

FYI, I have to give major thumbs up to Terabyte Unlimited's BootIt NG product. My laptop runs three partitions: Production, Development and Documents. Putting all my docs on their own partition means I can pave the other two pretty much whenever I want. However, Windows XP wants to make the first partition it finds the C drive, even if you eventually choose to boot off another partition. This means I can’t create an image from on partition and restore it to the other. What a pain. But with BootIt NG, I can choose which partition to boot and hide whichever of the others I want to.

I still use VPC for a lot of my dev work, but for Avalon and/or device development – where VPC isn’t really practical – having a separate partition for dev work is really helpful.

I’m sure lots of people are blogging a ton about PDC stuff, but I wanted to call out two things quickly.

First is Microsoft Max. I have a friend on this team, so I’ve heard a bunch about this. Given the number of pictures I have taken of my kids, I can’t wait to play with this in earnest.

Second is LINQ or Language Integrated Query and it’s use in C# 3.0 and VB 9.0. I started to write a language a few years ago called Dart (named after my dog) that had SQL-esque commands that were strongly typed. So I’m really impressed with what they’ve acomplished in LINQ. Not only is it doing strongly typed queries in the lanugage, they even can do joins across stores! In the keynote demo, they joined a query of running processes with data from a database. So now any C# or VB developer has their – or should I say will have their – own query processor around at the ready!

So as a quick break from all this architecture talk, I’ve got a code smell question. Here’s a scenario, I’m interested in feedback on the best way to solve the issue.

I’m writing some VSTO code for Word using VS05. I want to be able to add and update custom properties on the document. You do this via the CustomDocumentProperties property off the document object. This DocumentProperties collection supports the standard collection type operations such as Add and an indexer. However, it’s a little exception happy. If you attempt to access a property that doesn’t exist, it throws an exception. And if you attempt to add a property that already exists, it throws an exception. So the first time you set a custom property you use the Add method and then after that you use the indexer to access the existing item in the collection and update it’s value.

Of course, the way my code is written, I want to hide this ugliness behind a method so that the rest of my code can simply set custom properties with ease. However, I want to use the same method regardless if the item already exists in the collection. So what’s the best way to implement the method? I can think of two primary ways.

1. Attempt to access the custom property via the indexer. If it throws an exception, trap it and call Add instead.
2. Manually iterate through the existing custom properties. If the property exists, update it directly. If it doesn’t, call Add instead.

Neither of these is particularly fragrant from a code smell perspective, but which is less odorous? The first one is more direct to write, but since this is all COM interop code, the COM exception is pretty generic. Theoretically, if something else caused an exception to be thrown, I’d still assume the custom property was just missing and swallow the exception, potentially causing an error somewhere else. However, writing the code to manually iterate through the collection just seems excessive.

In the end, I went with #2 as I was more worried about swallowing exceptions than manual iterating though the collection. What do you think? Was that the right choice?

Not that I do a bunch of Office development, but I did build a pretty nifty utility for PowerPoint a while back. Getting it installed on anyone elses machine, however, was a pain in the ass because while I always remember to install the Office Primary Interop Assemblies when I install Office, I’m fairly certain I’m in the minorty on doing so. So installing Build Slide Exporter was alway tricky. Now, the Office PIA’s are available as a seperate install. Not sure if you can redist them, but the readme file that comes with the installer specifically mentions “Wrap the O2003pia.msi in another setup package through Visual Studio or other Windows Installer aware setup editor” so it sounds like they expect it to be redistributed.

Certainly not my father’s C++. I sat thru a presenation on VC++ 2005 today. Wow, I hadn’t realized all the coolness there.

First off, all the syntax is working it’s way thru the standards bodies, so no more underscore underscore syntax. It makes the code somewhat easier to read, but more importantly it’s following a similar standardization process to CLI and C#.

Secondly, you can now use all the native C++ features (templates, multiple inheritance, buffer overrun protection, etc) and all the CLI features (garbage collection, generics, language interop) together. Previously, you had very limited choices for mixing the two coding idioms. No longer – go ahead and mix and match. This gives you the best of both worlds. Use templates, and expose them to other .NET languages as generics.

Finally, it brings deterministic finalization to .NET. In VC++ 2005, you can declare both a destructor (used when a class goes out of scope or is explicitly deleted) and a finalizer (used when the class is garbage collected). This is similar to the whole IDisposable approach for classes that wrap unmanaged resources (file handles, network sockets, etc). Actually, it’s identical to IDisposable because that’s how it’s implemented! And it works both ways – if you instance a managed class that implements IDisposable “on the heap” then it will automatically call dispose at the end of scope. For example:

{  //C++ Version
   FileStream fs = FileStream(path, FileMode::Create);
   fs.Read(...);
   fs.Write(...);
}  //fs.Dispose called automatically

Even though the FileStream is implemented in C#, it behaves here like a stack type and is destructed as you would expect. In C#, you’d have to use a using statement to achieve the same effect. For this trival example, it’s not that big a deal. But if you have multiple stack instances created at different times within a scope, this helps out immensely.

Not sure I would move to C++ for all my managed programming, but I’ll certainly be giving VC++ 2005 another look.