Upgrading My Office Solution to a VSTO SE Application-Level Add-In

What is important for me to remember is that VSTO Second Edition solutions produce application-level managed code masquerading as COM Add-Ins. Microsoft, through its crack Office Team, will do everything in their power to protect its customers from possibly malicious application-level code. This is probably why my VSTO SE template opens a ‘default’ Add-In Project with a Setup project that cannot run when deployed to a machine without Visual Studio and VSTO SE installed. I would love someone on this planet to prove me wrong (this year) by opening a VSTO SE (or later) solution in Visual Studio, compiling it and trying to run it on an “end user” machine. It is extremely frustrating that (for the sake of security paranoia) these Add-Ins fail silently—no writing to the registry, no post-deployment environment variables (like VSTO_SUPPRESSDISPLAYALERTS or VSTO_LOGALERTS), nothing but brilliant Office security.

There is an unnecessary layer of complexity that “allows” me to avoid using highly-secured COM Add-Ins. It involves installing VSTO SE on top of VSTO in a mess documented in “How to: Install Visual Studio Tools for Office” and “Features Available by Product Combination.” In “Office Solutions Architecture Overview” Microsoft casually introduces this inelegant catastrophe by soothing:

The types of solutions you can create depend on which combination of Microsoft Visual Studio 2005 Tools for the Microsoft Office System (VSTO 2005) or Microsoft Visual Studio 2005 Tools for the 2007 Microsoft Office System (VSTO 2005 SE) you have installed.

You see, I made the ‘stupid’ mistake of assuming that VSTO 2005 SE was an independent upgrade to VSTO 2005—and the implied message from Microsoft was that document-level solutions are a technique of the past—which further implies that by opening a VSTO SE (or later) solution in Visual Studio, compiling it and trying to run it on an “end user” machine is easy to do. As of March 2007, four freaking guys, Darryn Lavery, Lubo Birov, McLean Schofield and Brian A. Randell, had to write an article to show me how incorrect my assumptions are. “Deploying Visual Studio 2005 Tools for Office Second Edition Solutions Using Windows Installer (Part 1 of 2),” is 22 printed pages—and this is just part one!

There are two hints in this article that might help explain why my VSTO SE Add-In is not working on an “end user” machine. Hint one:

When you consider the type of evidence that you want to use to trust the solution, avoid relying solely on location-based evidence. Instead, think about combining location-based evidence with a strong name, a digital certificate, or both.

Hint two:

Included with this article is a sample Microsoft Visual C# 2005 custom action (SetSecurity) to grant trust using both the folder location of the installed assembly and its strong name as evidence. The custom action sample assumes that there is only one main customization assembly and that you plan to deploy the entire solution to a local hard disk.

It took me way too long to figure out that OfficeVSTO2005SEWindowsInstaller.msi “included with this article” contains several C# projects (silently installed under %ProgramFiles%\Microsoft Visual Studio 2005 Tools for Office SE Resources\VSTO2005SE Windows Installer Sample)—one of which is called SetSecurity.csproj, eventually I’m going to figure out how to add it to my VSTO SE solution because Microsoft is a leader in innovation and so full of smart people.

Optimistically speaking it might take me an hour to try this out—and the emphasis is on try. You see this SetSecurity shit (that should have shipped with VSTO SE in the first freaking place to appear by default in new VSTO projects) is supposed to grant Full Trust to my Add-In. However, when I run caspol –rsg from the .NET 2.0 folder, toward my VSTO assembly this is the output:Microsoft (R) .NET Framework CasPol 2.0.50727.42

Level = Enterprise

Code Groups:

All code: FullTrust

Level = Machine

Code Groups:

All code: Nothing

1.1. Zone - MyComputer: FullTrust

Level = User

Code Groups:

All code: FullTrust

Success When my assembly runs, Microsoft Word disables it. I can run the COM Add-Ins… command in Word and see the checkbox unchecked. This behavior is by design and is recognized in “How to: Re-enable an Application-Level Add-in That Has Been Disabled” with the following note:

When you re-enable a soft-disabled add-in, the application immediately attempts to load the add-in. If the problem that initially caused the application to soft disable the add-in has not been fixed, the application will soft disable the add-in again.

What’s that… about five MSDN documents so far? So far there is no explanation as to why my add-in is disabled at start up—only the rumor that SetSecurity (and possibly strong naming) will solve the problem (some people proudly mention in newsgroups that they get their VSTO SE Add-In to run by installing the assemblies in the GAC—an unattractive, extreme solution). When I was a 26-year-old VBA programmer back in the 1990s this would have been an exciting challenge. Now in the post-Ruby-on-Rails world, this looks to me like a bunch of corporate bullshit. (By the way, the information provided in “Macros and add-ins do not run when security is set to High in PowerPoint and Word” does not improve or even effect my situation. Such a KB article would emerge out of some tech support rep’s ass to waste even more of my time.)

(What can the DLR do for Office Development? It promises a great deal—especially with a form of managed VBScript as (perhaps) VBA.NET—but the DLR won’t improve this crappy Office security model that severely punishes the developer.)

Another misery is the discovery that “How to: Prepare End User Computers to Run Office Solutions” indirectly leads to “Microsoft Visual Studio 2005 Tools for Office Second Edition Runtime (VSTO 2005 SE) (x86)” or VSTOR. The VSTOR that’s downloadable appears to be a few megabytes smaller than the one that ships with VSTO SE. My suspicions run wild with the possibility that VSTOR is stale and Microsoft Update is not keeping up with the latest stuff. Of course, my suspicions are just animalistic hysteria and the cool heads up in Redmond are simply misunderstood, right?

To further drive me into a frothing frenzy of fictional savagery, is the article “How to build an Office COM add-in by using Visual C# .NET,” which was reviewed in May of 2007—clearly within the VSTO SE timeframe. This article does not even mention VSTO or VSTO SE but revives the bare-metal approach of using only a Class Library project. I may have to waste spend more time trying this out just see how this works (or does not work)…

This just in: in the course of writing this article, the crazy idea of turning to open source appeared before me. Common sense asks, ‘Why does the OpenXML/ODF Translator Add-in for Office team have no bugs or known issues related to my freaking problems?’ The answer might lie in the documentation that comes with their source code! It points to this document: “FIX: Add-ins, smart documents, or smart tags that you create by using Microsoft Visual Studio 2005 do not run in Office.”

rasx()