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 (2007 System).

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

• A program database (PDB) file.

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 (2007 System).

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

• 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.

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 (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.

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

For 2007 Microsoft Office system projects, Visual Studio Tools for Office uses an inclusion list and certificates to verify the publisher. Visual Studio automatically creates a temporary certificate to identify Office solutions, and adds an entry to the inclusion list to trust that certificate. 

For more information, see Security in Office Solutions (2007 System).

For Microsoft Office 2003 projects, Visual Studio Tools for Office includes a Boolean property called Trust Assemblies Location. This property appears 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 by 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. Therefore, you do not need administrative credentials 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 about security, see Security Requirements to Run Office Solutions (2003 System).

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 every 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.

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 How to: Grant Permissions to Folders and Assemblies (2003 System).

For 2007 system 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 (2007 System).