I’m not going to go into detail about everything in the VS 2008 SP1 package, but what I would like to point out some key deployment features that were added and why you would want to consider installing even if you have a large user base using a base VS 2008 customization. In this discussion I will refer to things as being RTM (meaning VS 2008 and VSTOR 3.0 Pre SP1) and SP1.
Adding VSTOR 3.0 and .NET 3.5 SP1 Patch Redistributable’s:
We’ve added some additional functionality to the base VSTOR 3.0 Runtime that you can actually take advantage with RTM Applications. As such, if you install the SP1 patch on your development machine, you should be able to include the SP1 patches for both .NET 3.5 and VSTO Runtime 3.0. Adding these patches to the bootstrapper will not upgrade your existing customers but any new customers you have will be able to take advantage of the new functionality without any changes on your end. Any previously existing customers could re-run the Setup.exe file to receive the upgraded functionality.
One thing to keep in mind for these changes I’m describing is that the customization itself is not being upgraded, just the runtime it runs on is. If you have to recompile your customization against the SP1 Runtime to take advantage of a new feature, your customization will not work for your customers who don’t install the SP1 patches.
Additional Redistributable Package, the Office 2007 PIAS:
We’ve authored an Office 2007 PIA installer for general consumption. In general, Office 2007 will install the PIAs by default, specifically it will install them if you have a .NET Framework installed on your machine at the time you install Office. The problem with this is that it turns out a lot of you out there still use XP and clean installs of XP do not come with .NET installed. As such we’ve included a PIA redist package that you should be able to include. This package looks for a previous instance of an Office PIA existing on the machine before it does anything that might require elevation.
Specifically any deployment errors that occur on your client machines will by default log the error directly into the windows event log. The functionality here isn’t particularly rich, we’ve basically taken the same information that we display in the "alert dialog" that turning off VSTO_SUPPRESSDISPLAYALERTS enables. The key here is that you should now be able to excavate what the actual cause of error was even if the issue is resolved before you get a chance to investigate.
In RTM the timeframe in which an update can be "successfully" canceled is very small. If the user cancels the updated outside of that particular window the VSTO Runtime sees it as an error case and blocks further execution of the customization. Based on your feedback, we changed this behavior in SP1 such that you should now be able to cancel an update and continue running the previously installed version. There are still cases where an error will occur (an example would be if you are installing the customization for the first time) but in general this should be a lot closer to what you guys told us you wanted.
Thank You for Reading.