Blog - Title

Understanding the Architecture of Office 2010 Managed Add-Ins and Customizations

Understanding the Architecture of Office 2010 Managed Add-Ins and Customizations

  • Comments 0

The most important technology for building Office applications is that of managed customizations (including application-level managed add-ins, and document-level customizations).  Understanding the architecture and capabilities of managed customizations enables you to place the various developer technologies in context.  It is important to know which building blocks are integral to managed customizations, which building blocks provide the foundation for managed customizations, and which building blocks commonly are used in conjunction with managed customizations to provide users with the necessary functionality.

This blog is inactive.
New blog: EricWhite.com/blog

Blog TOC
This post is one in a series on Microsoft Office 2010 application development. These posts will be published in the future as part of an MSDN article. As usual, after the MSDN article is published, I’ll place pointers in the blog posts to the article on MSDN.

  1. Office/SharePoint Building Blocks and Developer Stories
  2. Overview of Office 2010 Application Development
  3. Office Application Scenarios
  4. Understanding the Three Approaches to Office Development using VSTO
  5. What is the Difference between ‘Word Automation’ and ‘Word Automation Services’?
  6. Understanding the Architecture of Office 2010 Managed Add-Ins and Customizations
  7. Understanding the Difference between Custom Task Panes and Action Panes
  8. Microsoft Word 2010 Developer Building Blocks
  9. Comparing Excel Automation to Excel Services

As I mentioned in Overview of Office 2010 Application Development, managed customizations consists of .NET classes that wrap the underlying COM libraries.  Because add-ins wrap COM libraries, there are some differences between these class hierarchies when compared to other .NET class libraries.

  • You rarely instantiate objects.  Instead, in your code in a managed add-in, you are passed an already created object graph that represents the underlying document or spreadsheet.  You then navigate from one object to another in the object graph.  Instead of explicitly instantiating new objects, you often request the framework to create one.  In the post, What is the Difference between ‘Word Automation’ and ‘Word Automation Services’?, the code example shows requesting the paragraphs collection to create a new paragraph.  This is, in effect, a factory method that creates a paragraph object.
  • In some cases, the programming interface does not follow the naming conventions for .NET.

Other than these differences, while the class hierarchies for each of the various applications are extensive, they are straightforward and easy to use.  For example, in the Word object model, you commonly work with the Application, Document, Paragraph, and Range classes.  See the Word Object Model Overview for more information.  In the Excel object model, you commonly work with the Application, Workbook, Worksheet, and Range classes.  See the Excel Object Model Overview for more information.

You can build managed add-ins for Word, Excel, Outlook, PowerPoint, Project, Visio, and InfoPath.  For the other applications, you need to use COM or other developer technologies to extend them.

One key difference between writing COM interfaces and writing a managed add-in is that when building applications using the COM interfaces, you could place ActiveX controls in the document or spreadsheet.  When writing a managed add-in, you use host items and host controls, which extend the underlying COM interface with some amount of additional functionality, a few more events, and the ability to use .NET Windows Forms controls on the surface of the document.  See Host Items and Host Controls Overview for more information.

When you create a new Office 2010 project in Visual Studio, you must pick from one of a variety of project templates.  Following are the project templates for C#.  VB.NET, of course, has the same set of templates.

 

The following table details the varieties of add-ins:

Project Template Name

Description

Excel 2010 Add-in

Application-level add-in

Excel 2010 Template

Document-level customization that creates and customizes an Excel template

Excel 2010 Workbook

Document-level customization that creates and customizes an Excel workbook

InfoPath 2010 Add-in

Application-level add-in

Outlook 2010 Add-in

Application-level add-in

PowerPoint 2010 Add-in

Application-level add-in

Project 2010 Add-in

Application-level add-in

Visio 2010 Add-in

Application-level add-in

Word 2010 Add-in

Application-level add-in

Word 2010 Document

Document-level customization that creates and customizes a Word document

Word 2010 Template

Document-level customization that creates and customizes a Word template

 The difference between a document-level add-in that creates a template and a document-level add-in that creates a document or workbook is that when the user uses the add-in to create a template (either a document or spreadsheet), the user opens a template to create a local copy as a new document.  They cannot modify the original template unless they are given special permissions.  See Office Project Templates Overview and Document vs. Template Solutions for more information.

SDK: Features Available by Office Application and Project Type

Developer Center: VSTO Developer Center

MSDN: Office Solutions Development Overview

Leave a Comment
  • Please add 5 and 2 and type the answer here:
  • Post