Share via

Building Office Solutions

  • Article

In general, building and debugging Office projects is the same as building and debugging other types of projects in Visual Studio, such as Windows Forms. The topics in this section explain the differences that do exist. For general information about how to build applications, see Building Applications in Visual Studio.

Project Output for Office Projects

The output location for Office projects is projectname\bin\release or projectname\bin\debug. You cannot build to a deployment directory.

Document-Level Projects

When you build a document-level project, the following items are included in the project output:

  • A copy of the project document.

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

  • The application manifest, which has the file name extension .manifest. For more information, see Application Manifests for Office Solutions.

  • The deployment manifest, which has the file name extension .vsto. For more information, see Deployment Manifests for Office Solutions.

  • A program database (PDB) file.

Note

If you build a document-level solution to a remote location instead of the local computer, add the fully qualified path to the Trusted Locations list in the application's Trust Center. For more information, see the section called Granting Trust to Documents in Securing Office Solutions.

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, which has the file name extension .manifest. For more information, see Application Manifests for Office Solutions.

  • The deployment manifest, which has the file name extension .vsto. For more information, see Deployment Manifests for Office Solutions.

  • A program database (PDB) file for the project assembly.

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 Registry Entries for Application-Level Add-Ins.

If you build an Outlook add-in project that contains form regions, the build process adds the following additional information to the registry:

  • A key for each message class that is associated with one or more form regions.

  • An entry for each form region and an associated value that represents the name of the Outlook add-in.

Outlook needs this information to load the form regions.

Referenced Assemblies

You can reference assemblies (including class library projects) from your Building Office Solutions 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.

Security during the Build Process

Visual Studio automatically configures the security settings on the development computer to grant trust to the solution during the build process. This allows the solution to run while you debug it.

Office projects use certificates to verify the publisher. Visual Studio automatically creates a temporary certificate to identify Office solutions, and configures the development computer to trust the temporary certificate.

For more information, see Securing Office Solutions.

Network Projects

If the assembly or document location is on a network share, the local (User level) security policy update is not enough to allow 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 how to set security policy, see Securing Office Solutions.

For document-level projects, you must also add the fully qualified location of the document to the Office trusted folders list. For more information, see Granting Trust to Documents.

Changing the Platform Target

By default, the platform target for Office projects is Any CPU. Typically, you should not change this setting. Office solutions that are built with the Any CPU platform target setting run in 32-bit and 64-bit versions of Microsoft Office 2013 or Office 2010.

You should set the platform target to x64 only if you are creating a solution that will run only in 64-bit versions of Microsoft Office 2013 or Office 2010, and your solution calls native 64-bit APIs. For more information about changing the platform target setting, see How to: Optimize an Application for a Specific CPU Type.

If you set the platform target to x64, the solution will not run in 32-bit versions of Windows or Office. The x64 platform target requires the solution to run in a 64-bit process.

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 that are created by the build process.

Title

Description

Debugging Office Projects

Presents issues involved in debugging Office projects.

Walkthrough: Creating Your First Document-Level Customization for Excel

Demonstrates how to create a basic document-level customization for Excel.

How to: Re-enable an Add-in That Has Been Disabled

Describes how to re-enable an add-in that has been hard or soft disabled.

Designing and Creating Office Solutions

Provides links to information about creating Office solutions, and about the role of assemblies in your solution.