Mucho disappointing: only available for VS2008/Office 2007. The docx file is available for any Office 2003 VSTO devs who want to read about what they're missing ;)

Download details: VSTO Power Tools v1.0.0.0

Update:
Phillip Hoff left a comment mentioning that the VSTO Power Tools contains Office 2003 assemblies, too, but your project has to target .NET 3.5 because the libraries are built using extension methods and LINQ. Sad for me, but maybe good news for someone else!

Molly brought home the fancy Dell Precision laptop (a giant 17" ~15lb behemoth) from her office and sat on the couch with it to do some work. I left for a few hours, and when I returned home, I noticed an odd odor when I walked in the door, but after a brief look around, I couldn't identify the culprit. I gave up and made something to eat. Later, when Molly packed up her laptop, she complained that the power supply was too hot to touch, and had to wrap it in several coils of cord before she could safely put it in her bag. A short while later, I noticed that the power supply had, in fact, melted a bright impression of itself into the fabric of our couch. That really sucks. Photo coming soon.

XKCD is on a roll this week:

Molly has been the victim of this pattern many, many times. Damn youse internets!!

xkcd - A webcomic of romance, sarcasm, math, and language - By Randall Munroe

In case you needed to know more than the definition of that awful industry euphemism "downer cow", the Humane Society has broken a huge story of animal abuse at a California slaughter house. The meat packer in question is one of the largest suppliers to the American school lunch program, and the scandal has lead to the largest beef recall in US history. Killing the cows is an understandable part of the beef-making process, but what kind of people would willingly participate in the torture of the animals first? The pictures and videos are extremely disturbing, so watch at your own risk.

NPR short radio story (same warning applies): Beef Recall Follows Animal-Abuse Scandal (NPR)

Gotta love XKCD. To any high school or college-aged female readers: this doesn't change when you get a job. Sorry.

I know this is a strong statement, but I come bearing evidence (WARNING: don't actually try this unless you want to wreck your machine):

Let's say you have a typical windows installation that has had many installations and patches applied to it. The folder C:\Windows\Installer is probably several gigabytes in size. Let's also say you have a small C drive and you need some extra space. Common sense tells us NOT to delete things from the Windows folder, so let's take the approved, documented, standard approach, and create a junction point (symbolic link in unix) between this very large folder and a folder on some other volume.

The process is simple: move Installer to a more spacious volume, and use a junction utility to create a link between the new location and C:\Windows\Installer. OK, you've recovered gigabytes of space on C and everything is great. Now all you have to do is NEVER EVER REBOOT YOUR MACHINE. Why, you ask? Well, because when the windows installer service restarts, it deletes the Installer folder (and its contents) if it's a junction point and then recreates it as a normal--empty--folder. Isn't this exactly what Microsoft told us NOT to do to shit stored in the Windows folder? Well, apparently it's OK when they do it.

Or not.

You see, the proper way to delete a junction point is to use the junction API to remove the link. When you use a shell API to delete the folder, it destroys the target folder contents, because links look so real to the regular windows APIs that the operations they perform apply transparently to the linked contents! Why on Earth the Windows Installer team designed their services to EVER under ANY circumstances destroy the installer folder is beyond me. It's probably beyond them, too. Anyhow, you're screwed. Figure every app you've installed or patched to that point is persona non grata to the Windows Installer service. Any data or shell icons are wrecked, and you will not be able to apply future updates to them or even uninstall them. You can install over them, but it's actually more reliable to reinstall windows.

FYI: I go to Microsoft conferences. If you work for the Windows Installer team and I meet you, be prepared for me to yell at you for this. This is the kind of technical cluelessness that legitimizes all of the MS haters out there on sites like slashdot.

Charlie Calvert introduces a new blog series called "Future Focus" that will detail upcoming changes to the C# language. In part 1, he shares an upcoming dynamic typing implementation for C# that is currently in incubation called Dynamic Lookup. Basically they want to provide new control structures or language semantics to imply dynamic typing on certain declared objects. This has implications for COM interop, CLR and DLR assembly interop, and new reflection tricks. The proposed version detailed in Charlie's article employs a "using{}"-like structure called "dynamic{}". You can declare a class-level field of type object and reference it across property or method calls within the class, but you have to wrap all references with a dynamic{} control structure.

I'm not impressed with the implementation syntax, but they're getting there. A comment on the blog proposed the keyword "dynamic" for new field/variable declaration, and I like that a lot better. I know that a dynamic{} control structure is probably an order of magnitude easier to implement in the lexer and compiler, but it will definitely make your code look like ass. I think they'll realize after incubating this a bit longer (and after more customer feedback) that developers want to access dynamically-typed and statically-typed objects the same way after declaration. I'm also be very interested in what Visual Studio intellisense support will be like at design time when I try to access classes written in a DLR language or when I use reflection under this new system.

On the COM interop side, this will have the effect of providing support for optional parameters to C#. Finally! Eight years after VB, us C# developers can finally stop adding the 30 Type.Missing parameters to every method call against an Office Programmable Interop Assembly!! Holy balls does that make my Office code look terrible. Maybe this can also simply reflection syntax?

Charlie Calvert's Community Blog : Future Focus I: Dynamic Lookup

I dropped some comments on .Net Kicks about what I thought was an atrociously biased and intellectually insulting response to the recent study On the Effectiveness of Test-first Approach to Programming. Reading through some of the author's other blog entries, I shouldn't have wasted my time; he seems to fancy himself some sort of lone-wolf TDD counterrevolutionary (I'm using an overwrought metaphor because he seems to take special exception anytime someone speculates metaphorically about his state of mind in a blog comment ;) Anyhow, his rhetorical style in his latest entry ("TDD or POUT") reveals him for the reactionary zealot he truly is. These methodology warriors are just plain boring.

Here's some good advice for anyone seeking to avoid the "zealot" label in their writing: If you won't even try a trivial act you write about all of the time, don't be surprised when nobody trusts your opinion about its merits. NEXT!

TDD Proven Effective! Or is it?