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 SharedVSTO9.0VSTOInstaller.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?