VSTO: Defective by Design

The company I work for provides resource scheduling solutions, mainly in the form of web and database server software coupled with an Outlook addin client. It is a complex addin that gets deployed to thousands of users in large corporate environments, and it is something I spend a sizeable amount of my time working on.

It is entirely written in old school COM, and has quite a history. Due to various reasons, there has been a strong pull to rewrite the software using newer technologies (.NET). I have recently begun the design and implementation of the new addin, and one of the first things I stopped to take a look at was VSTO.

The motivation for making the technological move lies completely with the ability to use .NET, among other issues with the current incarnation’s design. The ability to use VSTO was not the basis for the move; however, we would have gladly used it if the benefits were high.

I found VSTO to be incredibly disappointing due to a single, yet extremely powerful, reason. This single reason actually has caused me to question Microsoft’s view on addin development in general. Read on for my analysis of VSTO’s crippling fault, and why it makes the platform almost useless (at least for any serious addin development). I will also offer (what I view as) the correct course of action to take in regards to the serious problems caused by this crippling fault.

The first thing that you must understand is what VSTO (Visual Studio Tools for Office) is.

To be brief, it is a sort of managed environment designed to allow managed addins to be hosted in Outlook securely. The greatest immediate benefit gained by using VSTO is the secure hosting of your managed addin via a COM addin proxy component known as a shim.

Use of a shim is not required. However, you are foolish if you deploy a managed addin without one. Remember, Outlook (and the rest of Office), is still, through-and-through, entirely COM. None of that .NET nonsense here. Managed addins directly hosted by Outlook (no shimming occurring) all run in the same ApplicationDomain. Needless to say, this is not an ideal situation for your addin to be in.

If another, poorly written, managed addin crashes, so will yours. This is not the only possible negative event that may occur when you aren’t shimming your addin, but it is probably the most noticeable and common.

I would hope that you do not need any more reasons as to why shimming is absolutely essential for a managed addin that you intend to sell.

A COM addin proxy component is not the most difficult thing in the world to produce, but I’m assuming it would be regarded as an inconvenience to write for many .NET developers. Using VSTO solves this problem for you automatically!

There are other benefits to using VSTO; feel free to read about them on some other site. It is extremely important, however, that besides the avoidance of directly implementing the IDTExtensibility2 interface, the Outlook programmatic experience does not change at all. You still need to use the same objects, and are required to take the same precautions.

The use of VSTO results in additional dependencies, including the VSTO runtime. This is not a small dependency; rather, it is a large one that requires a significant amount of care in order to deliver on thousands of systems without incident. There are plenty of deployment horror stories one can find simply by consulting Google. In the long run, however, this is not that big of a deal.

The use of VSTO also adds a fair amount of overhead, as you are going to be working with a framework that is bound to have a multitude of things you don’t need. This is just the nature of making use of unoptimized solutions. Given the power of today’s hardware, you might not care, but you really should, unless you enjoy surrounding your products with inefficient bloat. Again, in the long run: not a big deal.

The detractors I’ve listed above should not be considered to be serious issues. With proper care and execution, you should be able to work around them just fine. However, there is one show-stopping, gigantic, and ultimately tragic flaw with VSTO:

A VSTO hosted addin can only be loaded by the user that installed it.

Let me rephrase that:

You cannot perform a per-machine installation of a VSTO hosted addin.

Outside of networks or machines found in homes or very small workplaces, installations are performed through the use of a package deployment system. With these systems, an administrative-level account is used to actually perform the installation. The installed software is then used by a different, user-level account. This is how deployment works when you are using package deployment systems such as SMS to install software on thousands of machines in your organization.

The environment I just described above can also be referred to as an “enterprise” or “large corporate” environment. The implications of all this is:

VSTO hosted addins do not support enterprise environments.

Visual Studio Tools for Office may as well be the greatest software ever written. None of that would matter, however, given the above fact. It simply causes VSTO to become a non-option for solutions that cater to any sort of multi-user environment.

One must pause and ask the question: Why is Microsoft crippling an otherwise good framework by adding this draconian restriction? Addins built upon VSTO technology are basically being delegated to a kind of software kiddie pool. Microsoft clearly does not view your addin to be a serious, enterprise-level piece of software if you are using VSTO.

Sure, there exist various hacks one may use in order to deploy to all users. But, that’s just what they are: sloppy hacks. You are very likely compromising the integrity of your design and introducing frequent points of failure by screwing that much around.

So, to sum things up: If you previously made a decision to use VSTO as the platform for your new addin, and your target demographic is anything that falls under the definition of a multi-user network, then you made a mistake.

I’m sorry if all of this sounds too severe, as I’m sure that the VSTO package, as a whole, can be attributed to the efforts of many talented and intelligent people. It is just that the lone reason illustrated above is truly a show stopper for any solution intended to be on the level of enterprise.

What is the correct course of action here (and what did I decide to go forward with in regards to our product)? Create your own custom COM shim. Don’t know how? Well, hopefully you enjoy learning new things as much as me. Don’t like it…? Hmm…tough?

A great resource for creating your own COM shim is Andrew Whitechapel, who has provided Visual Studio addin COM Shim Wizards that you can use in order to get a head start on things. Documentation relating to COM shims for Office addins can be found on MSDN as well.