In an attempt to make this easier to read here are a few terms I will be using frequently in this article:
Some of our customers have raised an issue with the bootstrapper failing after deploying their customizations onto a user’s machine that has previously had VSTOR & VSTORSP1 installed.
The problem occurs when an end user installs VSTOR followed by VSTORSP1 then subsequently uninstalls VSTOR from the Add/Remove Programs wizard. The uninstall removes the entire product including the service pack but fails to update the registry keys that our bootstrapper uses to detect if VSTOR is installed. If a user then installs a customization using the bootstrapper it will incorrectly detect that VSTOR is installed and proceed to install VSTORSP1, at which point it fails.
I recently responded to a customer on the VSTO forums ( http://social.msdn.microsoft.com/Forums/en-US/vsto/thread/2dd02b04-cc89-47c3-8f76-462ecfbee65e ) regarding this issue where I approached it from an end-user perspective, providing them with a list of fixes for post-deployment use. The purpose of this article is to provide a solution that developers can utilize so that end-users machines do not require post-deployment modification.
This workaround will allow developers to bake the correct VSTOR detection logic into every customization they develop that utilizes the bootstrapper.
Here is what you need to do:
And that’s it! Now that you have made these changes to your product.xml, every VSTO customization you build and deploy with a bootstrapper will correctly detect if VSTOR is installed regardless of what state the end-users machine is in.
This week Microsoft is hosting an internal even called Tech Ready 8 in Seattle. Microsoft technical field reps and product teams come together to talk about all of the great products we're building. I presented a session on Building Office Development Applications with Visual Studio along with a couple team members. In preparation for that session we spent the past week building a demo application that surfaces LOB data exposed as an ADO .NET dataservices in Outlook and Excel clients and SharePoint. Beth Massi is doing a blog series on how we wrote the soloution. Check it out.
After you develop Office solutions with Visual Studio Tools for Office, you can use Visual Studio 2008 SP1 to simplify your deployment experience. First, you can take advantage of the smaller .NET Framework Client Profile to decrease download time. Next, the Office 2007 primary interop assemblies (PIAs) are included in-the-box with VS2008 SP1 to avoid having to generate bootstrapper manifests. Finally, you can also troubleshoot any installation problems with the event viewer.
Develop your Office 2007 solutions against the .NET Framework Client Profile. The large size of the .NET Framework 3.5 SP1 can lead to long download times. The .NET Framework Client Profile is only 25MB in size, so download times are reduced when installing from the component vendor's web site. For more information about how to configure your solution to use the .NET Framework Client Profile, see How to: Target a Specific .NET Framework.
Deploying the Office 2007 primary interop assemblies is now (mostly) hassle-free. Visual Studio 2008 SP1 includes the Office 2007 PIAs as part of the update. This relieves you from having to download the PIA installer, download a code sample that contains the bootstrapper manifests, move the manifests to a certain directory, compile the ComponentCheck.cpp file to verify that the correct version of Microsoft Office is installed, and dance the hula. Instead, developing with one of the Visual Studio Tools for Office project templates already marks the Microsoft Office 2007 primary interop assemblies as a prerequisites. All you have to do is right-click on the project in Solution Explorer and click Publish.
Troubleshooting the installation and deployment process is more transparent. Any errors that occur are now logged in the event viewer. For example, I deliberately installed the same Office solution twice to generate the following error in the event viewer. Developers commonly see this error when they build and debug an Office solution on their development computer, and then try to install the Office solution on the same development computer. To avoid this problem, use a different account to test the installer on the development computer, or use a different test computer. For more information about the event viewer, see Event Logging (2007 System).
Visual Studio 2008 SP1 also introduced ClickOnce manifests that do not need to be signed. However, Visual Studio Tools for Office relies on signed manifests to identify the publisher and determine if the Office solution is trusted. Optional signing is a feature in VS2008 SP1 that does not apply to Office developers. For more information about trusting Office solutions, see Granting Trust to Office Solutions (2007 System).
Mary Lee, Programming Writer.
Rachel Shaw, Program Manager.