COM Shim Wizard - Microsoft Helps, but I'm Still Torn

A few days ago a great article titled Isolating Office Extensions with the COM Shim Wizard was published on MSDN from three geeks I respect (Andrew Whitechapel, Misha Shneerson, Siew Moi Khor). This article explains how to isolate Microsoft Office extensions from each other and why you should do so. It also shows a set of new Microsoft Visual Studio .NET wizards that automate the generation of COM shims for managed Office extensions.

Why do you need this? Bottom line, Microsoft Office 2003 has little knowledge or connectivity to .NET managed code. Now that doesn't mean you can't do managed code with Office, you can. But in most cases you are going through a layer of COM interop via the .NET framework. This sounds simple on the surface but it has been plagued with subtle issues. At the end of the day you are trying to get two very different systems to communicate and its not difficult for wires to get crossed.

The COM Shim Wizard discussed in this article tries to address some of the issues that can come up in making Office and .NET work together. I've used early betas of this tool and it is simply excellent. It works for COM Add-ins, Smart Tags and Real-time data components. It solves a few key problems:

• Application Domain Isolation - Letting your add-ins run independent of other .NET add-ins. This is important because isolation prevents add-ins from breaking each other.
• Better control over .NET Framework security for your add-in
• And More!

Torn?
Now why did I say that I am torn about this? I still think Microsoft needs to build in .NET managed extensibility into Office that hides all the complexities of building and add-in with .NET. The average developer has to learn about a lot of moving pieces just to get this all to work and it shouldn't be this hard.

So thanks for the toolkit, but when is the managed extensions problem really going to be solved?