Designing and Creating Office Solutions

Visual Studio 2010 provides project templates that you can use to create several different types of Office solutions. This section of the documentation describes the project templates and provides guidance about creating Office projects. For information about how to implement code and user interface customizations after you have created your project, see Developing Office Solutions.

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.

Creating Office Projects

Before you begin, you should determine your requirements and discover the type of solution that offers the best fit. For example, if your Office solution must run every time the application is used, an application-level add-in best fits your requirements. If the code is tightly integrated with a single document, create a document-level customization. These project types are available as Visual Studio project templates. For more information about the Office project templates that are included with Visual Studio 2010, see Office Project Templates Overview. For more information about how to create Office projects, see How to: Create Office Projects in Visual Studio.

Office projects have features and project items that are different from other types of projects in Visual Studio. For example, when you create a document-level project, the document or workbook in your project can be opened and edited inside Visual Studio. For more information, see Office Projects in the Visual Studio Environment.

If your customer base uses both Microsoft Office 2010 and the 2007 Microsoft Office system, you can develop a solution that works in both versions of Office. For more information, see Running Solutions in Different Versions of Microsoft Office.

Choosing a .NET Framework Version

After selecting the project type that best fits your requirements, you can choose which version of the .NET Framework to use in your development process. You can target the following .NET Framework versions in Office projects:

  • .NET Framework 4

  • .NET Framework 4 Client Profile

  • .NET Framework 3.5

The .NET Framework version that you choose for your project is required on end user computers for your solution to run. For example, if your project targets the .NET Framework 3.5, the .NET Framework 3.5 is required on end user computers. In this example, your solution will not run if only the .NET Framework 4 is installed on end user computers.

You can change the target framework after you create an Office project. However, after you change the target framework, you might need to modify some of the code in your project if it uses certain features. For more information about how to change the target framework, see How to: Target a Specific .NET Framework Version or Profile. For more information about changes you might need to make in your project, see Migrating Office Solutions to the .NET Framework 4.

If you change the target .NET Framework for your project and you are using ClickOnce to deploy your solution, make sure that you also select the corresponding version of the .NET Framework in the Prerequisites dialog box. This selection does not change automatically when you change the target framework for your project. For more information, see How to: Install Prerequisites on End User Computers to Run Office Solutions.

Note

You cannot target the .NET Framework 3.0 or earlier in Office projects. Office projects require features that were first introduced in the .NET Framework 3.5.

Differences Between Projects that Target the .NET Framework 4 and the .NET Framework 3.5

When you target the .NET Framework 4 in an Office project, you can use certain features that are not available when you target the .NET Framework 3.5.

Feature

.NET Framework 4

.NET Framework 3.5

Deploy solutions without Office primary interop assemblies

When you target the .NET Framework 4, you can deploy solutions without the Office primary interop assemblies (PIAs).

When you target the .NET Framework 3.5, the Office primary interop assemblies (PIAs) must be installed on the end user computer before your solution will run.

C# features that simplify Office development

When you target the .NET Framework 4, you can use late binding to simplify the code you write to work with the Office object models. For more information, see Late Binding in Office Solutions.

When you target the .NET Framework 3.5, you must explicitly cast objects and use reflection to access late-bound members. For more information, see Late Binding in Office Solutions.

Understanding When the Office PIAs Are Required on End User Computers

When you create an Office solution that targets the .NET Framework 3.5, the Office PIAs must be installed and registered in the global assembly cache on each end user computer that runs the solution. In most cases, the PIAs are installed by default with Office, but you can also include the PIA redistributable as a prerequisite for your solution. For more information, see Office Solution Prerequisites for Deployment.

When you create an Office solution that targets the .NET Framework 4, the Office PIAs do not need to be installed on end user computers if the Embed Interop Types property of each Office PIA reference in the project is set to True (this is the default value). In this scenario, the type information for the PIA types that are used by your solution is embedded into the solution assembly when you build the project. At run time, the embedded type information is used instead of the PIAs to call into the Office application's COM-based object model. For more information about how types from PIAs are embedded into your solution, see Type Equivalence and Embedded Interop Types.

Understanding the Client Profile

The .NET Framework Client Profile is a subset of the full .NET Framework. You can target the .NET Framework Client Profile if you need to use only the client features in the .NET Framework and you want to provide the fastest possible deployment experience for your Office solution. For more information, see .NET Framework Client Profile.

When you create an Office project that targets the .NET Framework 4, the .NET Framework 4 Client Profile is targeted by default. If you want to develop for the full .NET Framework 4, you must set this option after the project is created. For more information, see How to: Target a Specific .NET Framework Version or Profile.

Creating Solutions for the 64-bit Edition of Microsoft Office 2010

Microsoft Office 2010 is available in 64-bit and 32-bit editions. To create Office solutions that can run in either edition, the platform target setting for your project must be set to Any CPU. This is the default value for Office projects. For more information, see Office Solution Build Process Overview.

There are separate 64-bit and 32-bit versions of the Visual Studio Tools for Office runtime that are used by the 64-bit and 32-bit editions of Microsoft Office 2010. For more information, see Visual Studio Tools for Office Runtime Overview.

See Also

Tasks

How to: Create Office Projects in Visual Studio

How to: Target Office Applications Through Primary Interop Assemblies

How to: Set Up Configuration Information for an Office Solution

Concepts

Office Projects in the Visual Studio Environment

Properties in Office Projects

Running Solutions in Different Versions of Microsoft Office

Assemblies in Office Solutions Overview

Application and Deployment Manifests in Office Solutions

Globalization and Localization of Office Solutions

Common Tasks in Office Programming

Other Resources

Office Project Templates Overview

Using Office Functionality Inside of Visual Studio

Deploying Office Solutions

Developing Office Solutions

Architecture of Office Solutions in Visual Studio