Looking to the future, anticipating the next version of VSTO.
As we start to see that hazy object that is the “next version” of VSTO coalesce into an actual shippable project, my time and topics of interest have had a chance to increase again. One of the things current on my mind is “servicing”, specifically, what are the “predictive” measures you should take to as reasonably as possible “future-proof” your solution.
Before I get into any interesting code projects, I’m going to share some thoughts about some of the interesting tidbits that have come across my plate:
This section references statements made in the following post: https://blogs.msdn.com/krimakey/archive/2008/04/18/click-once-forced-updates-in-vsto-ii-a-fuller-solution.aspx
In a previous post I explored what it would take to duplicate some of the functionality that the ClickOnce deployment API provides. One of the things that was far from my mind at that point was “what happens in the next version”. Well, one of the really big changes that has occurred is the location of VSTOInstaller.exe. If you were to write a VSTO 3.0 solution using my example today, and your customer were to install the next version of VSTO Runtime, there is a good chance your background updates would be broken. But all is not lost!
One option is to simply extend the solution to also check for the newest version of VSTOInstaller. This isn’t ideal since you really don’t want to update your solution every time a new version of VSTO is released to the world. Unfortunately I can’t provide you with a bulletproof option to handle the next version of VSTO. What I can do though, is provide enough information that you are more likely to be successful in predicting what the next version is going to look like.
If you install a Beta version of the Visual Studio 2010 Tools for Office Runtime you may note the following installation key:
(x86)
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VSTO Runtime Setup\v4]
"Install"=dword:00000001
"InstallerPath"="C:\\Program Files\\Common Files\\Microsoft Shared\\VSTO\\10.0\\VSTOInstaller.exe"
(x64)
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VSTO Runtime Setup\v4]
"Install"=dword:00000001
"InstallerPath"="C:\\Program Files\\Common Files\\Microsoft Shared\\VSTO\\10.0\\VSTOInstaller.exe"
This key is the key to figuring out which (copy) of VSTOInstaller you should be using to install/update your solution.
[DISCLAIMER] Anything in the next section is based on a “best guess” approach based on observation only. I make no guarantees to the future validity of the method against future versions of the VSTO Runtime.
It’s very likely the next version of the VSTO runtime is likely to follow as similar pattern. Based on this assumption, you should be able to write a fairly resilient bit of code that might reduce the need to make updates to your solution based on changes in the VSTO runtime installation.
The safest method would be to grab all of the sub keys under [STO Runtime Setup] and iterate through looking for sub keys that contain an InstallerPath value. Take the highest version you find, and you _probably_ will be safe using that path to invoke VSTOInstaller.
[/DISCLAIMER]
The reason you would want to do this is simple: VSTO 4.0 was designed to replace the functionality provided by VSTO 3.0. If you install VSTO 4.0, and then attempt to install VSTO 3.0, VSTO 3.0 will detect that it does not need to be installed. This means you can no longer make the assumption that your customization will be running only against the VSTO 3.0 runtime. Additionally, even if your customer installed VSTO 3.0 and then installed VSTO 4.0, installing with the older VSTOInstaller may produce unexpected effects (you may incur some extra processing on the first run (post update) of your customization as some new meta-data that VSTO needs won’t be written).
[Correction 2/3/2010] After a bit of investigation, it turns out I was incorrect in stating VSTO 4.0 prevents VSTO 3.0 from being installed. You can install VSTO 3.0 on a machine with VSTO 4.0. This doesn’t change the basic fact that once VSTO 4.0 ships, you should “plan” for your customizations to be installed on VSTO 4.0 only machines also. While the Bootstrapper will always cover installation of prerequisites (such as VSTO 3.0) there isn’t a guarantee that it will get run on machines that have VSTO 4.0 on them. VSTO 4.0 does install the mime handler that makes .vsto files “installable”, depending on the situation, it’s reasonable for a customer to skip running setup.exe program and go right to installation of the customization.