ISWIX, LLC View Christopher Painter's profile on LinkedIn profile for Christopher Painter at Stack Overflow, Q&A for professional and enthusiast programmers

Friday, January 18, 2008

Learning To Deploy VTSO 3 AddIns

Edit: Follow-up article VSTO Lessons Learned

I'm writing this open letter to anyone who can help me ramp up faster on learning the best practices for deploying VSTO 3 Add-In's written in Visual Studio 2008 targeting Office 2007. I've done a bunch of googling, asked for help in multiple forums but no one else seems to have gone down this road yet.

I'll share first what I have learned..... VSTO is basically a big adapter pattern / thunking layer framework to make it super easy to write managed code add-ins for Microsoft Office without all of the hassle of interop. I'm probably summing this up to simplistically but hey, I'm just a Setup Developer not a VSTO Developer.

The developer that I'm working with has created a .VSTO file which is basically a ClickOnce project generated by Visual Studio. We don't want to use ClickOnce to deploy the AddIn because we really have a bunch of AddIns to deploy along with .NET Framework 3.5, VSTO 3, several other prereqs, various system components, GAC assemblies and other managed applications such as tray apps and system services.

So currently I'm writing an MSI to lay everything down on the machine and then call out to %CommonProgramFiles%\Microsoft Shared\VSTO\9.0\VSTOInstaller.exe /Silent /Install [TARGETDIR]Foo.vsto.

The above is technically workng working but I'm really not happy with it. It looks a lot like the ugly devenv /setup CA calls I see Votive use in WiX. I feel caught between a rock and a hard place.... the Windows Installer purists proclaim that EXE CA's are full of danger to be mitigated ( why it's not mitigated in the EXE hosting model is a blog for another day ) and yet the VSTO people don't see to have given me any other choice.

Edit: I've noticed that calling VSTOInstaller installs the add-in only for the current user. If I run it as Deferred System Context the interactive user won't see the add-in. If I run it as Deferred then the user will but other users won't. This might require me to do some per-user pattern hacks.

Does anyone have any suggestions?


  1. You can deploy outlook addin with setup, that write to register all that need. but Visual Studio can help to create setup to your project with all that "write to register". For that you need to create addin in VS2008 with addinn 2003 outlook project (need to install VSTO SE).
    But for addinn 2007 outlook project, VS could not create setup project that bad.
    You can read book "Visual Studio Tools for Office Using C with Excel Word Outlook and InfoPath" for understand more.

  2. These links might be of help for people struggling with VSTO deployment:

    They use the '|vstolocal' postfix on the manifest key to disable ClickOnce installation of the .vsto file and 'proper' authenticode certificate to avoid trust prompts. You could also do a custom action to add the add-in to the 'Inclusion List'

    It is still only a per-user solution, but I believe you might be able to use registry value propagation to get the hkcu bits in the right places for each user. A link I found about propagation:

    Hope these help.

  3. This post is a few months old and I need to replace it with a new one ( and a white paper / sample project ) detailing what I learned on deploying VSTO Addins.

    I was all over the blog posts and forum topics mentioned by others and a summary of what I learned can be found here: