Office Solutions Development Overview
By using Microsoft Office as the front end for solutions, you can take advantage of the familiar Microsoft Office user interfaces and tools such as the word processing features in Word, the data analysis features of Excel, and the e-mail management features of Outlook. You can develop solutions in Visual Studio to customize Office applications and add the specific features you need for your business processes. For example, you can turn Word into a contract generator that assembles contracts out of pre-existing parts that can be made editable or not editable. With Excel, you could create an automated budget worksheet customized for different projects. Your users can also take Office solutions offline, which makes complex solutions more practical than they would be if you use a Web-based architecture.
This topic provides an overview of the types of Office solutions that you can create by using the Office developer tools in Visual Studio 2010. For general information about how to develop with Office, see the Microsoft Office Developer Center.
Visual Studio provides the following types of project templates for Office development:
Document-level customizations. This type of solution is associated with a specific document.
Application-level add-ins. This type of solution is associated with the application itself.
To decide which of these project types is best for your solution, think about whether you want your code to run only when a specific document is open, or whether you want the code to be available whenever the application is running. For more information about the project templates, see Office Project Templates Overview.
The types of projects you can create depend on which Office applications you have installed on the development computer. For more information, see Features Available by Office Application and Project Type.
Document-level customizations consist of an assembly that is associated with a single document, workbook, or template in Microsoft Office Word or Microsoft Office Excel. The assembly is loaded when the associated document is opened. Features in customizations that you create are available only when the associated document is open. Customizations cannot make application-wide changes, such as displaying a new menu item or Ribbon tab when any document is open.
Visual Studio includes tools to help you create document-level customizations. The document that you customize is hosted as a design surface in Visual Studio, which enables you to design the document by dragging and dropping controls onto it. Many other Visual Studio features are available in document-level projects, such as Windows Forms controls, drag-and-drop data binding, and an integrated debugger.
For more information about customizations, see the following topics:
Application-level add-ins consist of an assembly that is associated with a Microsoft Office application. Typically, the add-in runs when the associated application is started, although users can also load add-ins after the application is already running. Features in add-ins that you create are available to the application itself, regardless of which documents are open.
Visual Studio includes tools to help you create add-ins. Add-in projects include an automatically generated class that represents the add-in. This class provides properties and events you can use to access the object model of the host application and run code when the add-in is loaded and shut down. Many other Visual Studio features are available in application-level projects, such as Windows Forms and an integrated debugger.
For more information about add-ins, see the following topics:
You can programmatically incorporate the features of an Office application into your solution by writing code that accesses the application's object model. Object models are an arrangement of classes that expose functionality through various properties and methods. The object model for each Office application is different.
To use the object model of an Office application from a solution created by using the Office development tools in Visual Studio, you must use the primary interop assembly (PIA) for the application. The PIA enables the managed code in your solution to interact with the Office application's COM-based object model.
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.
For more information about using the PIAs in Office solutions, see the following topics:
When you create an Office solution, consider how the deployment requirements might affect your development choices.
Use ClickOnce or Windows Installer to deploy solutions that you create by using the Office development tools in Visual Studio. ClickOnce deployment enables you to create self-updating solutions that can be installed and run with minimal user interaction. Windows Installer (.msi) files can be easily distributed to end user computers, or distributed by using Systems Management Server (SMS). For more information about deploying Office solutions, see Deploying Office Solutions.
Before end users can run a solution you create by using the Office development tools in Visual Studio, their computers must have certain prerequisites installed. If you deploy your solution by using ClickOnce or by creating a Windows Installer file, these prerequisites can be installed with your solution. For more information, see Office Solution Prerequisites for Deployment and How to: Install Prerequisites on End User Computers to Run Office Solutions.
Security for Office solutions is enforced by a series of checks that the Visual Studio Tools for Office runtime makes when it installs and loads the solution. These checks include verifying whether the location of the deployment manifest is trusted or whether the certificate used to sign the deployment manifest is trusted. For more information, see Securing Office Solutions.