Troubleshooting Office Solution Deployment (2007 System)
The information in this topic applies only to the specified Visual Studio Tools for Office projects and versions of Microsoft Office.
Microsoft Office version
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.
Changing the Assembly Name Causes Conflicts
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.
Checking for Updates Takes a Long Time
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
In the registry, navigate to the following key:
In the AddInTimeout subkey, set the time-out value in milliseconds.
If the AddInTimeout subkey does not exist, create it as a DWORD.
Unable to Update or Publish to a Network File Share
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.
Prerequisites for the 2007 Microsoft Office System Are Not Installed
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.
Publishing Using 'Localhost' Can Cause Installation Problems
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.
Cached Assemblies Are Loaded Instead of Updated Assemblies
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
On the Project menu, click ProjectNameProperties.
On the Application page, click Assembly Information.
In the first Assembly Version box, type an asterisk (*).
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.
XML Schemas in Document-Level Customizations Are Not Registered
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).
Installation Fails When the URI Has Characters That Are Not US-ASCII
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.
Prompt to Manually Uninstall Appears When You Publish and Install a Solution on the Development Computer
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.
Uncaught Exception or Method Not Found Error When You Install a 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.
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.
Manifest Registry Keys for Add-ins Change After Building a Windows Installer Setup Project
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.
The ClickOnce Installer for Your Office Solution Does Not Install the Primary Interop Assemblies
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.
Visual Studio Tools for Office 3.0 Service Pack 1 Runtime Does Not Re-Install
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.
Added information for troubleshooting scenarios.
SP1 feature change.