Office Development with Visual Studio : MSI

VSTO Runtime bootstrapper package failure causes deployed customization installation to fail (Aaron Cathcart)

VSTO Team — Sat, 07 Feb 2009 11:48:00 GMT

In an attempt to make this easier to read here are a few terms I will be using frequently in this article:

VSTOR = Visual Studio Tools for the Microsoft Office System (version 3.0 Runtime) (x86)
VSTORSP1 = Visual Studio Tools for the Microsoft Office System (version 3.0 Runtime) Service Pack 1(x86)
Bootstrapper = the clickonce bootstrapper that gets deployed with a VSTO customization when there are prerequisites checked (setup.exe)

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:

On the development machine locate the file %ProgramFiles%\Microsoft SDKs\Windows\v6.0A\Bootstrapper\Packages\VSTOR30\product.xml
Replace the element
<RegistryCheck Property="VSTORuntimeInstalled" Key="HKLM\SOFTWARE\Microsoft\VSTO Runtime Setup\v9.0.21022" Value="Install"/>
with
<MsiProductCheck Property="VSTORuntimeInstalled" Product="{8FB53850-246A-3507-8ADE-0060093FFEA6}"/>
Alter the element
<BypassIf Property="VSTORuntimeInstalled" Compare="ValueGreaterThanOrEqualTo" Value="1"/>
to be
<BypassIf Property="VSTORuntimeInstalled" Compare="ValueGreaterThanOrEqualTo" Value="3"/>

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.

Deploying Office 2003 Solutions with Windows Installer (Mary Lee)

VSTO Team — Thu, 18 Dec 2008 02:08:05 GMT

You may want to develop Microsoft Office 2003 solutions with Visual Studio Tools for Office (VSTO) in Visual Studio 2008 SP1 for several reasons.

Your customers are using Microsoft Office 2003.
Your customers are using both Microsoft Office 2003 and the 2007 Microsoft Office system.
Your customers are using .NET Framework 2.0 and cannot migrate to .NET Framework 3.5.

Once you're done with development, you'll want to deploy your Microsoft Office 2003 solutions to your end users. This process involves the following steps:

Check for and install the following prerequisites: .NET FX 2.0, VSTO 2005 SE runtime, and the Microsoft Office primary interop assemblies. If your client computers already have the prerequisites, or you want to do this manually, you can skip this step.
Copy the customization assembly to the end user computer.
Grant full trust to the customization assembly.
For application-level add-ins only, create a set of registry keys so that the Office application knows to load the add-in.

Due to customer demand, I've created five deployment samples that demonstrate these steps. Step 1 is demonstrated in two ways: you can select your prerequisites through the Prerequisites Dialog Box to be installed with the Setup.exe bootstrapper; alternatively, you can configure launch conditions in the Setup project to only install the customization if the prerequisites already exist.

Prerequisites Dialog Box:

Launch Conditions editor:

You can use the Setup project to complete step 2 by copying the customization assembly and for document-level projects, the document or workbook, to the designated installation location. This is done by adding the project output with the File System Editor. The default installation location in these Setup projects is %PROGRAMFILES%\MyCompany\<Name of Setup Project>.

File System Editor:

Full trust is granted by using the SetSecurity project for step 3. This code uses a custom action in the Setup project to create a code access security policy that creates a solution code group for your Office solution, and an assembly code group for the customization assembly.

Custom Actions Editor:

Step 4 only applies to application-level add-ins: when you use the Excel 2003 add-in or Word 2003 add-in project templates, there is a Setup project automatically added to your Office solution that already creates the registry keys documented in Registry Entries for Application-Level Add-Ins.

Registry Editor:

The process of preparing the development computer for deployment and configuring the Setup project is written out step-by-step in the following two whitepapers:

Deploying Visual Studio 2005 Tools for the Office System SE Solutions Using Windows Installer (Part 1 of 2)

Deploying Visual Studio 2005 Tools for the Office System SE Solutions Using Windows Installer: Walkthroughs (Part 2 of 2)

Now, it's time to experiment on your own. Download the sample code and the completed installers from the MSDN Code Gallery: http://code.msdn.microsoft.com/VSTO2005SEMSI

Happy deployment!

Mary Lee, Programming Writer.

How to Include .NET Framework 3.5 SP1 with Your Installer (Mary Lee)

VSTO Team — Wed, 19 Nov 2008 01:55:00 GMT

Recently in the Visual Studio Tools for Office forum, a Visual Studio 2008 SP1 developer asked how to include the .NET Framework 3.5 Service Pack 1 in the same directory as the application. For example, you can select Download prerequisites from the same location as my application in the Prerequisites Dialog Box if your application is going out on CD and being installed without a network connection.

However, when you try to build your setup project or ClickOnce installer, you see the following error message: "The install location for prerequisites has not been set to 'component vendor's web site' and the file 'DotNetFX35SP1\dotNetFX20\netfx20a_x86.msi' in item '.NET Framework 3.5 SP1' can not be located on disk. "

What does it mean? The installers for .NET Framework 3.5 SP1 were not included in the VS2008 SP1 installer due to size restrictions. The default deployment experience is to download the .NET Framework 3.5 SP1 from the Microsoft Download Center during installation.

How do you include the .NET Framework 3.5 SP1? You can download the full .NET Framework 3.5 SP1 installer and extract the necessary files to the Visual Studio bootstrapper directory. After you modify the product.xml file and update the PublicKey value, the .NET Framework 3.5 SP1 will appear in the Prerequisites Dialog Box. You can find the full instructions in the Visual Studio 2008 Service Pack 1 Readme in section 2.3.1.1 Enable Samesite for the .NET Framework 3.5 SP1 bootstrapper package.

While these steps may seem lengthy, you only have to complete the steps once on your development computer. Then, every project you develop and deploy can include .NET Framework 3.5 SP1 as a prerequisite.

If you have further questions about deployment, visit the ClickOnce and Setup & Deployment MSDN forum to search for answers or ask your questions.

Happy deployment!

Mary R Lee, programming writer.

How Do I: Deploy Document-Level Office 2007 Solutions with Windows Installer? (Mary Lee)

VSTO Team — Thu, 02 Oct 2008 19:26:00 GMT

In Deploying an Office solution using Windows Installer, you read how to deploy document-level Office 2007 solutions with Windows Installer. As a follow up, you can now see how to add a Setup project to your VSTO solution and add a custom action to update custom document properties. This example uses Excel 2007, but you can apply these principles to any document-level customization.

Deploying Excel Document-level Customizations with Windows Installer

This video is based on the whitepaper: Deploying a Visual Studio Tools for the Office System 3.0 Solution for the 2007 Microsoft Office System Using Windows Installer (Part 2 of 2), where you can get the code and follow along step-by-step.

Mary Lee, Programming Writer.

How Do I: Deploy Application-Level Office 2007 Solutions with Windows Installer? (Mary Lee)

VSTO Team — Thu, 02 Oct 2008 19:21:33 GMT

In Deploying an Office solution using Windows Installer, you read how to deploy application-level Office 2007 solutions with Windows Installer. As a follow up, you can now see how to add a Setup project to your VSTO solution and create registry keys. This example uses Excel 2007, but you can apply these principles to any application-level add-in.

Deploying Excel Application-level Add-ins with Windows Installer

This video is based on the whitepaper: Deploying a Visual Studio Tools for the Office System 3.0 Solution for the 2007 Microsoft Office System Using Windows Installer (Part 1 of 2), where you can get the code and follow along step-by-step.

Mary Lee, Programming Writer.

Deploying an Office solution using Windows Installer (Mary Lee)

VSTO Team — Fri, 11 Apr 2008 03:39:00 GMT

Visual Studio 2008 offers a ClickOnce deployment experience for solutions developed for the 2007 Microsoft Office system. However, if you want to deploy additional files, add extra registry keys, or use SMS, you may still be interested in creating a Windows Installer package.

Here are the very basic steps to configure your setup project:

1. Add the release build or publish output of your solution. Then manually add the application and deployment manifests (.dll.manifest and .vsto files).

2. For application-level projects, create the registry keys so that the Microsoft Office application can find your add-in. For more information, see Registry Entries for Application-Level Add-Ins. For the add-in name, use a syntax similar to [CompanyName].[AddinName].

3. For document-level projects, update custom document properties which point to the location of the deployment manifest. If you leave the document in the same relative location compared to the customization assembly, you don't need to update the _AssemblyLocation property. But if you want to move the document to a user's desktop or Documents folders, you'll have to update the _AssemblyLocation property. For more information, see Custom Document Properties Overview.

You must still use ClickOnce security to trust your solution. You can deploy your .msi at this point, but you'll see a trust prompt asking whether the solution should be installed or not. To avoid prompting your end users, sign your manifests with a known and trusted certificate or pre-trust the solution by creating an inclusion list entry. For more information, see Security in Office Solutions (2007 System).

Bonus: there is sample code to help you complete the steps of deploying additional files, updating the document's _AssemblyLocation, and creating an inclusion list entry. Visit http://code.msdn.microsoft.com/VSTO3MSI in the MSDN Code Gallery to download the sample code.

For all the details, read the deployment whitepapers at Deploying a Visual Studio Tools for the Office System 3.0 Solution for the 2007 Microsoft Office System Using Windows Installer (Part 1 of 2) and Deploying a Visual Studio Tools for the Office System 3.0 Solution for the 2007 Microsoft Office System Using Windows Installer (Part 2 of 2).

If you run into trouble implementing this, visit the VSTO MSDN forum at http://forums.microsoft.com/msdn/showforum.aspx?forumid=16&siteid=1 to search for answers or ask your questions.

Mary Lee, programming writer.