A few months ago I was asked to write an Install that deployed a few .NET 3.5 features:
Tray Application (required)
Office 2003 Word Add-In ( Optional )
Office 2007 Word Add-In ( Optional)
At the time I blogged I was exploring these technologies and asked if anyone had already done it. Lately several people have emailed me asking if I ever figured it out. I have figured it out and during the process I confirmed that ClickOnce/VSTO Installer/Per-User Installs are STILL a BAD IDEA!! Using this process you can streamline (merge) multiple VSTO add-ins, other system components and related setup prereqs into a single All-Users install that can be deployed using traditional techniques.
I've been meaning to write a white paper with sample code on this subject but I've been too busy. Until then, here's a quick recipe using InstallShield 2008 ( InstallShield 2009 would be a little cooler using chained feature conditioned Setup Prereqs to streamline the relationship between the prereqs and the features. )
You'll need to bring a bunch of things together:
1) Download the .NET 3.5 Prereq ( Web downloader of Full Install from InstallShield )
2) Create the VSTO 2005SE and Office 2003 PIA Prereqs ( Conditioned for installation if Office 2003 Installed and made optional)
3) Create the VSTO 3.0 Prereq ( Conditioned for installation if Office 2007 Installed and made optional)
4) Blocking SystemSearch/Launch Conditions to check .NET 3.5 is installed.
5) SystemSearch / FeatureConditions to disable Add-In features if related Office versions aren't installed.
6) `Feature Constraints` to not allow the user to select the Office-Addins if the related Office versions aren't installed.
7) A .NET Class for calling referencing the System.Security.Cryptography namespace for calling the BCL methods for installing various certificates. These will be needed to backup the add-in manifest for run time verification purposes. ( Get rid of an annoying dialog that is bad if the user says no. )
8) A .NET class for calling the System.Random class to generate a random number.
9) Office 2007 doesn't allow Add-Ins to be installed Per-Machine but it does expose a rather interesting pattern for migrating data down to the user profile without invoking an MSI repair scenario. Unfortunately this pattern requires that you create a registry key during the uninstall ( which MSI doesn't support ) so you'll need a custom action for that also.
To understand this registry migration pattern, how Office loads Add-In manifests and the roll of signing, read through the following articles.... ( make your .NET developer read it also so that he can get on the right track of knowing how to build his code and where to expect the runtime execution to occur on the file system )
Deploying your VSTO Add-In to All Users (Part I)
Deploying your VSTO Add-In to All Users (Part II)
MSDN Forums: Merge (VSTO) Setups
This looks like a fairly complete list, having some something similar myself. We provided a less rich setup experience - check for the prereq; iF it wasn't there, abort the install, and inform the installer to get the prereq in place. Normally not an issue since the software was largely deployed via image or SMS.
ReplyDeleteOne question I did have, though - do you also need to ensure that the PIA (primary interop assemblies) are installed in Office as well?
I wrote this up from memory so let me go back to my source code and see if I did. I don't think I had to, put perhaps I did. I remember the 2003 plumbing fell into place a lot easier then the 2007 plumbing.
ReplyDeleteI needed the richer experience because the desire was to have a single install that targeted both office versions ( or no office ) thereby making the features ( and their dependencies ) optional.
I'll review my project and update where needed tonight.
Yes, I used the Office 2003 PIA's to support the 2003 add-in but PIA's weren't needed to support the 2007 add-in. I'll update the post.
ReplyDeleteThanks for the catch! I remember most of the hard work was getting the 2007 stuff to work. The 2003 came together so quickly and easily that I kinda forget what I had to do.
Here's a new post with information on the subject:
ReplyDeleteDeploying your VSTO Add-In to All Users (Part III)
I'm pretty new at this. How does this approach compare to something like Active Setup?
ReplyDeleteActiveSetup has a similar notion of detecting deltas between HKLM and HKCU.
ReplyDeleteThe differences are
1) It can be used for more then just Office 2007
2) It'll run a program instead of replicating registry data
In this scenario we don't need to support other programs and we don't need to actually run code since we only need simple registry replication.