Export (0) Print
Expand All

Office Solution Build Process Overview

Building your Microsoft Office solution is no different than building other applications in Visual Studio. However, there are a few things to keep in mind that are specific to Microsoft Office solutions, and there are some differences between document-level projects and application-level projects.

For more information about document-level and application-level projects, see Office Solutions Architecture Overview. For more information about building applications, see Building in Visual Studio.

Project Output

The output location for a Visual Studio Tools for Office project is <document name>\bin\release or <document name>\bin\debug. You cannot build to a deployment directory. For information about deploying Visual Studio Tools for Office solutions, see Deploying Document-Level Customizations and Deploying Application-Level Add-ins.

Document-Level Projects

When you build a document-level project for Microsoft Office Word or Microsoft Office Excel, the following items are included in the project output:

  • A copy of the project document.

    On build, the document is copied, and the copy is put in the output directory with the assemblies.

  • The project assembly and all referenced assemblies that have their Copy Local property set to true.

  • The application manifest (embedded in the document). For more information, see Application and Deployment Manifests in Office Solutions.

  • A program database (PDB) file.

For Excel solutions, you cannot change the output path, or working directory. If you set the working directory option in the Debug pane of the Project Designer to a different location, Excel will change it back to the default at run time when the document is opened. However, for Word solutions, you can change the output path normally.

Application-Level Projects

When you build an application-level project, the following items are included in the project output:

  • The project assembly and all referenced assemblies that have their Copy Local property set to true.

  • The application manifest. For more information, see Application and Deployment Manifests in Office Solutions.

  • A program database (PDB) file.

  • The build process for application-level projects also creates a set of registry entries on the development computer that are required to load the add-in. For more information, see Deploying Application-Level Add-ins.

Referenced Assemblies

You can reference assemblies (including class library projects) from your Visual Studio Tools for Office project. Every referenced assembly has a property called Copy Local. Copy Local indicates whether the assembly is copied to the output directory. By default it is set to true. Every referenced assembly that has Copy Local set to true is copied to the output directory.

Referenced Office Projects

You cannot reference a Visual Studio Tools for Office project from a different Visual Studio Tools for Office project, because the startup/initialization code of the referenced project will not execute.

Security During the Build Process

Visual Studio Tools for Office includes a Boolean property called Trust Assemblies Location. This property is located in the Properties window in Visual Studio. By default, this property is set to true. If the property is set to true, when you build the project, Visual Studio grants full trust to the project assembly using the URL as evidence. Full trust permissions are also granted to referenced and satellite assemblies that are in the output folder. Trust is granted at the User level for assemblies that are on the local computer, so you do not need administrator privileges for those projects. If you rebuild the project in a different location, the full trust permissions for the old location are removed. For more information on security, see Security Requirements to Run Office Solutions.

Checking the location and granting trust at each build enables you to move projects and share projects without having to change the security configuration of the computer manually each time. However, you must use the tools provided by Visual Studio to change the project location. If you use an external tool, such as Windows Explorer, Visual Studio is not able to update the permissions.

Network Projects

If the assembly or document location is on a network share, the local (User level) security policy update is not enough to permit the solution to run. An administrator must grant full trust at the Machine level to assemblies and documents that are on a network share before the solution will run. For more information about setting security policy, see How to: Grant Permissions to Folders and Assemblies.

Testing a Document-Level Word Solution

Press F5 to build and debug a solution. If you want to test a Word solution without debugging by building and then opening the document outside of Visual Studio, close the project before you open the document. When you open a Word document in Visual Studio, a flag is set on the Word process so that it does not run customizations. If you open a customized Word document outside of Visual Studio by double-clicking the file in Windows Explorer, the flag can prevent this document from running customizations as well. When you double-click the file to open it, Word opens the document in the same process as any currently-running document. Since a document is open in Visual Studio, the new document is opened in that same process and receives the flag not to run customizations.

Using the Clean Command

To remove the built project files from the development computer, you can use the Clean command on the Build menu in Visual Studio. The Clean command deletes all files in the build output location. For application-level projects, the Clean command also removes the registry entries created by the build process.


The Clean command does not remove the permissions that the build process granted to the solution assemblies. For information about removing permissions, see How to: Remove Permissions from Folders and Assemblies.

See Also

Community Additions

© 2015 Microsoft