VSTO Lessons Learned

tag:blogger.com,1999:blog-9537945.post-11527750491232697022008-04-21T18:32:00.005-05:002008-04-23T06:15:27.145-05:00VSTO Lessons LearnedA 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 ) <a href="http://blogs.msdn.com/mshneer/archive/2007/09/04/deploying-your-vsto-add-in-to-all-users-part-i.aspx" target="_blank">Deploying your VSTO Add-In to All Users (Part I)</a> <a href="http://blogs.msdn.com/mshneer/archive/2007/09/05/deploying-your-vsto-add-in-to-all-users-part-ii.aspx" target="_blank">Deploying your VSTO Add-In to All Users (Part II) </a> <a href="http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2707637&SiteID=1">MSDN Forums: Merge (VSTO) Setups</a>Christopher Painterhttp://www.blogger.com/profile/12167478740431444267noreply@blogger.com