Friday, May 22, 2009

Coolest. Tool. Ever.

I’m struggling with how to best start this post. Here are a few possibilities:

  • I like to think that I’m a hard person to impress. But…
  • I swear at my computer many times a day, but usually in anger and almost never in delighted surprise.
  • Someone deserves a raise.
  • Holy crap!

All of them apply, so you can take your pick.

But what am I talking about?

I’m talking about the DocumentReflector tool that’s included with the Open XML Format SDK v2.0.

You see, I’ve been playing today with a few Office development tasks today for a work-related project. I’ve never looked too closely at working with the Office Open XML file format before this week; I’ve read white papers and such, but until you start writing your own code you never really “get” what an API is all about. After a few false starts and many searches, I was less than impressed.

But then I discovered DocumentReflector. This is a stand-alone SDK tool that will (wait for it) let you open an Office Open XML document, select a subset of the document or the entire document and it (here it comes) displays the C# code that will create it.

Holy crap indeed.

I’m sure I’ll be swearing at this amazing tool before the weekend is over (the new wears off pretty quickly for me) but today whoever built this app is officially my hero.

Edit: I almost forgot to add – there’s a great overview of using this tool on Erika Ehrli’s blog, here.

Now I can’t help but ask why we don’t have a tool like this for SSIS packages. Wouldn’t it be great to point a utility at a DTSX file and have it output the code required to build that package through the SSIS API? ;-)


Unknown said...

For SQL Server 2000(and also 7) there was actually a way to generate a vbscript macro that recreated the DTS package through ActiveX DTS objects.
Since SSIS can be put into SCC MS didn't bother to add one for SQL server 2005 onwards. But until you can functionally diff and merge SSIS packages I consider SSIS packages a bit of a kludge in this respect. Without these options there is no way to do *real* version control on them.

Matthew Roche said...

@DM - If you check out the BIDS Helper project on CodePlex, you'll find functionality that makes diffing (although not merging) SSIS packages relatively simple. It's not ideal, but it's definitely functional, and I've done "real" version control on many packages on real projects.

The functionality that I see as missing is the ability to save a package as the .NET code that would re-create the package. This was included in DTS as you mention, and to me is a gap in the SSIS feature set. So many interesting scenarios are based on creating packages through code, but it's not always obvious how to use the SSIS .NET API to build complex packages - particularly the data flow. For me (I don't want to suggest all developers think like I do, so I need to be careful here to qualify this as my own personal opinion) there would be a HUGE benefit to be able to build a package in the designer, export that package as code, and then modify the code to make the package generation dynamic. This is what I see as the big benefit of the Document Reflector utility. Source control doesn't really enter into the picture here for me...

Sam X said...

I was just thinking the same thing. both for ssis packages as well for analysis services.

interested to participate in such project?