Can I deploy my and all of its prerequisites in one file? (Mary Lee)

VSTO Team — Wed, 14 Oct 2009 22:16:01 GMT

One frequent customer question is about how to deploy an application and all of its prerequisites in a single .msi or .exe file. This question applies whether you are deploying any of the following:

Microsoft Office 2003 solutions with dependencies on .NET Framework 2.0, Visual Studio Tools for Office 2005 SE runtime, Microsoft Office 2007 primary interop assemblies.
Microsoft Office 2007 solutions with dependencies on .NET Framework 3.5 , Visual Studio Tools for Office runtime 3.0, Microsoft Office 2007 primary interop assemblies.
Microsoft Office 2007 solutions with dependencies on .NET Framework 3.5 SP1, Visual Studio Tools for Office runtime 3.0 SP1, Microsoft Office 2007 primary interop assemblies.
Microsoft Office 2007 solutions with dependencies on .NET Framework 3.5 SP1 Client Profile, Visual Studio Tools for Office runtime 3.0 SP1, Microsoft Office 2007 primary interop assemblies.
Really, any WinForms/WPF/console/whatever app with dependencies on .NET Framework, SQL Server Express, SQL Server compact, Visual C++ runtime, Windows Installer, or anything else.

There are three concepts in deployment related to prerequisites: nesting, merging, and chaining or bootstrapping.

Nesting is the process of embedding a Windows Installer file (.msi) within another .msi file. However, the How to create a nested .msi package article has an important disclaimer.

The drawbacks of creating a nested MSI installation are listed in the same article.

Nested Installations cannot share components.
An administrative installation cannot contain a nested installation.
Patching and upgrading will not work with nested installations.
The installer will not correctly cost a nested installation.
Integrated ProgressBars cannot be used with nested installations.
Resources that are to be advertised cannot be installed by the nested installation.
A package that performs a nested installation of an application should also uninstall the nested application when the parent product is uninstalled.

For these reasons, nesting is no longer supported.

Merging includes shared code, files, resources, registry entries, and setup logic to applications as a single compound file. Prerequisites available as a merge module (.msm) form can be added to a .msi file. For example, if a prerequisite is available as an .msm, you can add it to a Setup project in Visual Studio as shown in How to: Create or Add a Merge Module Project. However, merge modules cannot be serviced by the same owner as the .msi file, so it is difficult to fix issues in the merge module. Tao of the Windows Installer, Part 4 lists two cautionary notes:

Do not consume merge modules of vendors who do not promise to fix their merge modules promptly when bugs arrive
Be prepared to handle the heat when bugs are found in your merge module causing issues for others’ products that have consumed your merge module and you get to put out the flame

For these reasons, using merge modules is not recommended.

Nesting and merging create a single file to deploy an application and its prerequisites, but these methods are not supported and not recommended. Thus, the answer to the question in the title is no: you cannot or should not deploy an application and its prerequisites in one file.

Chaining or bootstrapping is the process of checking for and installing missing prerequisites, including installing the application that is going to be used to install the rest of the prerequisites and application. You can use Visual Studio to generate a chainer/bootstrapper that is called Setup.exe. This program checks for and installs missing prerequisites before installing the application or Office solution.

If you are deploying an Office 2007 solution in Visual Studio 2008 SP1, the .NET Framework 3.5 SP1, Visual Studio Tools for Office 3.0 SP1 runtime, and Microsoft Office 2007 primary interop assemblies are already selected in the Prerequisites Dialog Box.

To learn more about how to install prerequisites in Visual Studio, see the following topics.

How to: Install Prerequisites on End User Computers to Run Office Solutions

How to: Install Prerequisites in Windows Installer Deployment

How to: Install Prerequisites with a ClickOnce Application

If the prerequisite package does not appear in Visual Studio, you can create your own bootstrapper package. After you create a product.xml file that describes the prerequisite and a package.xml files that includes locale-specific error messages, you can copy the bootstrapper package to \Program Files\Microsoft SDKs\Windows\v6.0A\Bootstrapper\Packages folder. For more information, see Creating Bootstrapper Packages.

Other tools besides Visual Studio: You can also use MSBuild and the GenerateBootstrapper Task to create a bootstrapper on a build computer. Alternatively, you can use the Windows Installer XML Toolset to generate .msi files and package prerequisites. For more information, see http://wix.sourceforge.net/.

For questions about bootstrapping, search for answers or post new questions in the ClickOnce and Setup & Deployment forum.

Happy deployment!

Mary Lee, Programming Writer.

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.

Office Development with Visual Studio : Bootstrapper

Can I deploy my and all of its prerequisites in one file? (Mary Lee)

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