Writing Code in Office Solutions
There are some aspects of writing code in Office projects that are different from other types of projects in Visual Studio. Many of these differences are related to the way the Office object models are exposed to managed code. Other differences are related to the design of Office projects.
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.
Managed Code and Office Programming
The key technology that makes creating an integrated Microsoft Office solution possible is Automation, which is part of the Component Object Model (COM) technology. Automation enables you to use code to create and control software objects exposed by any application, DLL, or ActiveX control that supports the appropriate programmatic interfaces.
Understanding Primary Interop Assemblies
Microsoft Office applications expose much of their functionality to Automation. However, you cannot use managed code (such as Visual Basic or C#) directly to automate Office applications. To automate Office applications by using managed code, you must use the Office primary interop assemblies (PIAs). The primary interop assemblies enable managed code to interact with the COM-based object model of the Office applications.
Every Microsoft Office application has a PIA. When you create an Office project in Visual Studio, a reference to the appropriate PIA is automatically added to the project. To automate the features of other Office applications from the project, you must add a reference to the appropriate PIA manually. For more information, see How to: Target Office Applications Through Primary Interop Assemblies.
Using Primary Interop Assemblies at Design Time and Run Time
You must have the Office PIAs installed and registered in the global assembly cache on your development computer to perform most development tasks. For more information, see Configuring a Computer to Develop Office Solutions.
The PIAs must also be installed on end-user computers to run Office solutions that target the .NET Framework 3.5. However, the Office PIAs are not required on end-user computers to run Office solutions that target the .NET Framework 4. For more information, see Designing and Creating Office Solutions.
Using Types in Primary Interop Assemblies
The Office PIAs contain a combination of types that expose the object model of the Office applications and additional infrastructure types that are not intended to be used directly in your code. For an overview of the types in the Office PIAs, see Overview of Classes and Interfaces in the Office Primary Interop Assemblies.
Because the types in the Office PIAs correspond to types in the COM-based object models, the way you use these types is often different from other managed types. For example, the way you call methods that have optional parameters in an Office primary interop assembly depends on the programming language you are using in your project. For more information, see the following topics:
Programming Model of Office Projects
All Office projects include one or more generated classes that provide the entry point for your code. These classes also provide access to the object model of the host application and access to features like actions panes and custom task panes.
Understanding the Generated Classes
In document-level projects for Excel and Word, the generated class resembles a top-level object in the application's object model. For example, the generated ThisDocument class in a Word document project provides the same members as the Microsoft.Office.Interop.Word.Document class in the Word object model. For more information about the generated classes in document-level projects, see Programming Document-Level Customizations.
Application-level projects provide a generated class called ThisAddIn. This class does not resemble a class in the host application's object model. Instead, this class represents the add-in itself, and it provides members you can use to access the object model of the host application and access other features available to add-ins. For more information, see Programming Application-Level Add-Ins.
All generated classes in Office projects include Startup and Shutdown event handlers. To get started writing code, you typically add code to these event handlers. To initialize your add-in, you can add code to the Startup event handler. To clean up resources used by your add-in, you can add code to the Shutdown event handler. For more information, see Events in Office Projects.
Accessing the Generated Classes at Run Time
When an Office solution is loaded, the Visual Studio Tools for Office runtime instantiates each of the generated classes in your project. You can access these objects from any code in your project by using the Globals class. For example, you can use the Globals class to call code in the ThisAddIn class from an event handler of a Ribbon button in an application-level add-in.
For more information, see Global Access to Objects in Office Projects.
See Also
Tasks
How to: Target Office Applications Through Primary Interop Assemblies
How to: Create Event Handlers in Office Projects
Concepts
Supported Programming Languages in Office Projects
Programming with Visual Basic vs. Visual C# in Office Solutions
Optional Parameters in Office Solutions
Global Access to Objects in Office Projects
Namespace Considerations in Office Solutions
Late Binding in Office Solutions