The topic you requested is included in another documentation set. For convenience, it's displayed below. Choose Switch to see the topic in its original location.

Troubleshooting Office Solution Deployment (2007 System)

Updated: July 2008

Applies to

The information in this topic applies only to the specified Visual Studio Tools for Office projects and versions of Microsoft Office.

Project type

  • Document-level projects

  • Application-level projects

Microsoft Office version

  • 2007 Microsoft Office system

For more information, see Features Available by Application and Project Type.

This section contains tips for solving common problems that you might encounter when you deploy Microsoft Office solutions by using Visual Studio Tools for Office.

If you change the Assembly Name value in the Application page of the Project Designer after you have already deployed a solution, the publishing tools will modify the Setup package to have one Setup.exe file and two deployment manifests. Deploying two manifest files can cause the following conditions:

  • If the end user installs both versions, the application will load both add-ins.

  • If the add-in was installed before the assembly name was changed, the end user will never receive updates.

To avoid these conditions, do not change the solution's Assembly Name value after you deploy the solution.

Microsoft Visual Studio Tools for the Microsoft Office system (version 3.0 Runtime) provides a registry entry that enables administrators to set the time-out value for downloading the manifests and the solution. 

To set the time-out value

  1. In the registry, navigate to the following key:


  2. In the AddInTimeout subkey, set the time-out value in milliseconds.

    If the AddInTimeout subkey does not exist, create it as a DWORD.

Office solutions that are on a network file share might display a misleading message during updates if the solution's Setup.exe file is locked in a process while the update is being published. The message might say the following: "Unable to add 'setup.exe' to the Web. The file 'setup.exe' already exists in this Web."

To help prevent file locking, you can make the share read-only to the end users. However, if documents are on the share, they will also become read-only to the end users.

You can add the Microsoft .NET Framework, the Visual Studio Tools for Office runtime, and the Microsoft Office primary interop assemblies to your Setup package as prerequisites that are deployed with your Visual Studio Tools for Office solution. For information about how to install the primary interop assemblies, see Installing Visual Studio Tools for Office and How to: Install Office Primary Interop Assemblies.

When you use "http://localhost" as the publish or installation location for document-level solutions, the Visual Studio Tools for Office Publish Wizard does not convert the string to the real computer name. This means that the solution can only be installed on the development computer. To make deployed solutions use IIS on the development computer, use the fully qualified name for all HTTP/HTTPS/FTP locations instead of localhost.

Fusion, the .NET Framework assembly loader, loads the cached copy of assemblies when the project output path is on a network file share, the assembly is signed with a strong name, and the assembly version of the customization does not change. If you update an assembly that meets these conditions, you will not see the update the next time that you run the project because the cached copy is loaded.

You can configure Visual Studio so that Fusion will download assemblies every time that the project is run.

To download assemblies instead of loading cached copies

  1. On the Project menu, click ProjectName Properties.

  2. On the Application page, click Assembly Information.

  3. In the first Assembly Version box, type an asterisk (*).

  4. Click OK.

After you change the assembly version, you can continue to sign your assembly with a strong name and Fusion will load the latest version of the customization.

If you attach an XML schema to a document in a document-level project for the 2007 Microsoft Office system, the schema is not registered in the user's library. You must create a separate installer file to do this. For more information, see XML Schemas and Data (Visual Studio Tools for Office).

When you publish a Visual Studio Tools for Office solution to an HTTP/HTTPS/FTP location, the path cannot have any Unicode characters that are not in US-ASCII. Such characters can cause inconsistent behavior in the Setup program. Use US-ASCII characters for the installation path.

When you build a Visual Studio Tools for Office solution, the built version is automatically registered. If you have previously published and installed the same solution to your development computer, Visual Studio Tools for Office detects that the installation path for the published version and the built version are different after the next build, rebuild, or publish. The error message says "the customization cannot be installed because another version is currently installed and cannot be upgraded from this location." Because rebuilding the solution updates the registry keys, it is necessary to uninstall the first version before publishing, debugging, or running the second version.

To prevent the message from appearing, create another user account on your development computer to test your deployment. Alternatively, you can uninstall the version from the list of installed programs on the computer before you next publish, debug, or rebuild the solution.

When you install Office solutions developed with Visual Studio 2008 Service Pack 1 (SP1) by opening the deployment manifest (a .vsto file), Office application, document, or workbook, you may see error messages for the following conditions:

  • Method not found.

  • MissingMethodException.

  • Uncaught exception.

To prevent these error messages, install the solution by running the Setup program.

Office solutions that are developed by using Visual Studio 2008 SP1 require SP1 for the Visual Studio Tools for Office 3.0 runtime. The Setup program checks for the correct version of prerequisites, including SP1 for the runtime, and installs them as necessary. However, when you install the solution without running the Setup program, the installer does not check for or install prerequisites.

The manifest registry key that is part of an add-in Setup program sometimes changes from .vsto to .dll.manifest when you build the Windows Installer Setup project.

To work around this issue, create the Setup project in a different solution, or use CompanyName.AddinName as the value of the registry key that contains the name of the add-in.

If you use Visual Studio 2008 SP1, you do not need to do this workaround.

When you run the Setup program that ClickOnce creates for your Office solution, the installer for the Office primary interop assemblies (PIAs) runs only if there are no PIAs already installed.

If the Setup program does not install the PIAs correctly, install the PIAs manually by running the installer file named o2007pia.msi from the install directory.

When you use the Setup.exe to re-install the Visual Studio Tools for Office 3.0 Service Pack 1 (SP1) runtime on a computer that previously had the Visual Studio Tools for Office 3.0 SP1 runtime installed, the installation may fail. To fix this error, delete the [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\vsto runtime Setup\] registry key and run the VSTO 3.0 SP1 installer again.




July 2008

Added information for troubleshooting scenarios.

SP1 feature change.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

© 2015 Microsoft