On the MSDN website, the Office and SharePoint Development in Visual Studio page discusses two primary options for developing an Office add-in: 1) use the latest and greatest Office add-in technologies targeting Office 2013, and SharePoint 2013, or 2) use Visual Studio Tools for Office (VSTO) to presumably target versions of the Office 2010 and older.
If you intend to distribute your Office add-in to the general public, don’t use VSTO.
VSTO offers many features to develop an add-in, including graphical editors to define Office UI customizations. It has extremely simple tools to manage deployment, and it magically loads code whenever the user starts your targeted Office application.
The problem with deploying it to the general public is that the VSTO Runtime (VSTOR) is a prerequisite that the user must have installed, and dealing with the VSTOR in the wild sucks. In our experience, a number of users simply could not install the VSTOR, and there were issues even with those who could.
VSTOR upgrades can leave behind problematic artifacts, and resulting failures often produce opaque error messages. You can find a number of complaints on the MDSN Forum about one particular artifact that VSTOR upgrades leave behind. Below is one example, with no apparent, official resolution—just an incomprehensible error message:
The value of the property ‘type’ cannot be parsed. The error is: Could not load file or assembly ‘Microsoft.Office.BusinessApplications.Fba, Version=188.8.131.52, Culture=neutral, PublicKeyToken=71e9bce111e9429c’ or one of its dependencies. The system cannot find the file specified. (C:\Program Files (x86)\Common Files\Microsoft Shared\VSTO\10.0\VSTOInstaller.exe.Config line 10)
Additionally, if your VSTO add-in takes too long to load, office applications can disable it. This is likely to happen, because the timer starts before the CPU reaches the add-in’s instructions. That’s right – your application can be penalized for “performance reasons” before your add-in is even loaded, nevermind starting to run. And if any of your potential users are on a slow computer, there is little that optimizing your code can do. Imagine our frustration trying to trace performance issues in our application when our users reported that it was disabled due to “being too slow” when the many reasons that it may be “too slow” didn’t involve our code at all.
The deployment mechanisms that VSTO borrows from ClickOnce can also fail, again with inscrutable error messages such as “Value does not fall within the expected range.” Here is another product’s support page that discusses a workaround that isn’t particularly user friendly.
Apparently, the VSTOR is prone to becoming corrupt. Our customer service representatives communicated that while troubleshooting with the user, our application started to work correctly when the user did nothing more than run the “Repair” tool for the VSTOR.
Common themes for these issues involve the development team spending too many hours on the following actions:
- Investigating incidents with paltry and inscrutable logs
- Identifying potential causes and fixes
- Experimenting with fixes under various foreseeable circumstances
- Experimenting with fixes in the wild
- Refining those fixes as users give us feedback
Some of these issues seemed intractable, even as users went to great lengths to avail themselves for troubleshooting. Others went silent after prolonged communications with our support team going through our support script. I imagine a large portion of folks simply walked away after encountering the first issue or two trying to set up our product; with the number of possible issues, many folks could fall into this category.
With all this doom and gloom, what alternative is there? There is some talk about approach that involves implementing the IDTExtensibility2 interface. There is also the suggestion to use a tool like Add In for Microsoft Office and .net, which seems to do the heavy lifting implementing IDTExtensibility and providing features that have allowed us to replace VSTO and overcome the aforementioned problems by avoiding them (the VSTOR) altogether.
Moving to Add In Express has been undeniably the right move for Yesware for Outlook product development rather than sticking with VSTO. No difficult-to-install, buggy prerequisite exists. Therefore, prospective users’ ability to install our product has greatly improved. The ADX loader has resolved the frequent complaints about our Yesware for Outlook being disabled due to slow loading.
There are still some issues for us to improve. We kept the ClickOnce deployment mechanism since we focused on removing the VSTO dependency first, but ClickOnce can sometimes fail in the same user unfriendly ways that were already mentioned before. Add In Express offers a deployment mechanism which leverages the Windows Installer which is likely to make our installer reliable. We are always working on improving our product, so expect an MSI option for Yesware for Outlook soon!