Publishing an Office Solution by Using Windows Installer
You can create a stand-alone installer program (.msi file) by using Windows Installer. You can then distribute that file to deploy Office solutions. The .msi file can also be distributed by using Systems Management Server (SMS).
Applies to: The information in this topic applies to document-level projects and application-level projects for Microsoft Office 2010 and the 2007 Microsoft Office system. For more information, see Features Available by Office Application and Project Type.
Setup Project Configuration
To create an .msi file to deploy an Office solution, follow this general process:
Create a Setup project. For more information, see How to: Create or Add a Setup Project.
Include the project output of your Office project in the Setup project.
Add the application and deployment manifests to the Setup project.
For application-level add-ins, configure the required registry keys.
For document-level customizations, configure the custom document properties.
Configure the Setup project so that the Office solution is granted trust to run. For more information, see Securing Office Solutions.
For more detailed instructions and examples, see Deploying a Visual Studio 2010 Tools for Office Solution Using Windows Installer.
Including Project Output
To configure your Setup project to include project output, you can add either the build or publish project output of your solution to your setup project. If you use the build project output, use only the files from the bin\release directory. Although the manifest files are in the same directory as the project output, the application manifest (.dll.manifest) and the deployment manifest (.vsto) must be added manually to the setup project. For more information, see Publishing Office Solutions by Using ClickOnce.
Registry Keys for Application-Level Add-Ins
You must enable the Microsoft Office application to discover and load the add-in by creating registry keys. The registry key location varies depending on the Microsoft Office application. (For Outlook, form regions require an additional registry key.) For the Manifest registry key, append |vstolocal, which loads your add-in from any location (such as %ProgramFiles%), instead of the ClickOnce cache.
Note
If you have Visual Studio 2010 Service Pack 1 (SP1) installed on your development computer, you must add the prefix file:/// to the manifest registry key. If you do not add this prefix and your add-in reads data from the application configuration file, users might receive an error when the add-in loads.
For more information, see Registry Entries for Application-Level Add-Ins.
Document Properties for Document-Level Customizations
Document-level customizations do not use registry keys. Instead, the location of the deployment manifest is stored in custom document properties. For more information, see Custom Document Properties Overview.
The Publish Wizard updates the document properties to point to the customization assembly on a file share or web site. When you use Windows Installer, you must manually change the value of the _AssemblyLocation property to point to the deployment manifest as a custom action in your Setup project by using the ServerDocument class. For more information, see How to: Attach Managed Code Extensions to Documents.
Deploying to AllUsers
Starting in Visual Studio 2010, you can use Windows Installer to deploy Office 2010 application-level add-ins to AllUsers. Installing and uninstalling add-ins requires administrator privileges. The security model still relies on ClickOnce. Therefore, the certificate that is used to sign the application and deployment manifests should be trusted at the machine or enterprise level. Otherwise, each user may be prompted to verify that the add-in is trusted.
The registry keys that you add to the Setup project vary if you want to install to AllUsers or just the current user. We recommend that you use the |vstolocal suffix to load the add-in from a different location than the ClickOnce cache. For more information, see Registry Entries for Application-Level Add-Ins.
Inclusion List
Office solutions installed to the Program Files directory require administrative rights to install. Because the Office solutions were already granted FullTrust permissions during installation, the Visual Studio 2010 Tools for Office Runtime no longer completes the extra step to check the inclusion list to verify if the certificate is trusted.