Office Solution Build Process Overview
Building a Microsoft Office solution is very similar to building other applications in Visual Studio. However, there are several things to consider that are specific to Office solutions.
For general information about how to build applications, see Building in Visual Studio.
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.
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.
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 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.
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 the 2007 Microsoft Office system and in 32-bit and 64-bit versions of Microsoft 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 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, including the 2007 Microsoft Office system. 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.
See Also
Tasks
How to: Build Office Solutions
Concepts
Debugging in Document-Level Projects