Understanding the Three Approaches to Office Development using VSTO

[Blog Map]  This blog is inactive.  New blog: EricWhite.com/blog

When using Visual Studio Tools for Office (VSTO), there are three basic approaches to Office development:

• Application-Level Managed Add-In
• Document-Level Customization
• Office Automation

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

Under the covers, the Office client applications use COM to expose their functionality.  One of the uses of COM in Office is to develop an add-in, which is code that the Office client application loads and runs as the user operates the Office client application.  There are specific mechanisms that Office uses for add-ins, including placing DLLs in appropriate places, configuring code access security to enable running the code, and creating registry entries so that the Office client applications know of the existence of the add-in.

Visual Studio Tools for Office layers a .NET managed programming interface on top of the COM interfaces.  This is immensely valuable – the Microsoft developers who built VSTO take care of many issues around building COM applications, and free us up to develop the functionality that meets our customers’ needs.  The .NET run-time is a managed run-time; hence the name of an add-in built using VSTO is a managed add-in.  The .NET assemblies that are layered over COM are called the Office Primary Interop Assemblies (often called PIAs).

There are two approaches to building a customization of Office.

• Application-level add-in – This type of add-in’s functionality is available regardless of which document, spreadsheet, or presentation is opened.  An example of this variety is a department-wide or corporate-wide application that enables some level of functionality that every employee of the department or corporation needs to access on a regular basis.  As an example, Lexis for Microsoft Office is an Office customization targeting legal firms.  Users need to execute the same code for every document, so it is implemented as an application-level managed add-in.
• Document-level customization – This type of functionality is part of the document.  In this scenario, .NET managed assemblies (code-signed for security purposes) are attached directly to each document, so if you send the document to a new user, they can open the document and use the add-in’s functionality without explicitly installing an add-in.  For example, a tax analysis department needs to systematically analyze documents for their tax implications and then communicate that analysis back to the document author.  The result of that analysis is associated with a specific document, so it makes sense to build a document-level add-in that manages the process of assessing and optimizing the tax implications of that document.  Actually, in this case you might have an application-level add-in that is used by the tax analysis firm that produces a document that is customized with a document-level add-in.
  
  In another case, a large consulting and accounting firm produces spreadsheets that implement sophisticated calculations that would be difficult to implement directly using Excel formulas.  They use a document-level add-in so that they can send spreadsheets to associates in other firms or to their customer, and those recipients can take advantage of the code in the document-level add-in.  Note that with Office 2007 and Office 2010, document-level customizations are available only for Word and Excel.

The third approach to use the COM interfaces (both directly and through the PIAs) is Office Automation.  You can develop an automation application that runs an Office client application to perform some specific task.  Your application may have the appearance of a traditional Windows application.  It may even be a simple console application.  When you run this application, under the covers, the application runs the Office application (such as Word 2010 or Excel 2010) and uses it to accomplish the desired task.

Applications that use Office Automation are not intended for unattended server-side automation.  The Office client applications are, at their core, user applications.  They may put up dialog boxes and require user input.  The issues around server-side Office client automation are well-known.  Instead of using Office automation, the modern approach is to use the Open XML SDK combined with Word Automation Services.  The Open XML SDK and Word Automation Services are server-hardened tools.  You can accomplish many word-processing scenarios using them.  The resulting application will be much more reliable, and will have better performance than if you build it using Office automation.  There are very few word-processing scenarios where it is better to automate Office than to use the Open XML SDK and Word Automation Services.  Note that while the name of Word Automation Services has the word 'Automation' in it, Word Automation Services is not automating Office on the server.  Word Automation Services is a service that comes with SharePoint Server 2010.  It is a service that you can use in combination with the Open XML SDK to accomplish word-processing scenarios.

In contrast, there are many Excel scenarios where we recommend using Office automation (although not unattended server-side automation).  Modification of an Excel spreadsheet is fairly involved.  For instance, if you insert a row, you probably want to update all formulas that reference cells below the inserted row.  This is not trivial, and would rely on a formula parser and a fair amount of logic.  Instead, for many scenarios, it is better to use Excel automation.  Another approach to accomplishing some scenarios is to use Excel Services, which is a service that comes with SharePoint Server 2010 Enterprise.

Regardless of whether you are building an application-level add-in or a document-level customization, your extensions fall into one of two categories:

• Your extension may enhance the user interface.  For example, you may develop an extension that adds a new tab to the ribbon, and exposes functionality through an action pane or custom task pane (more on these shortly).
• Your extension may directly manipulate open documents, spreadsheets, or presentations.  For example, you may develop an application that inserts a pre-formatted table with data retrieved from a corporate database.

Typically, a application-level managed add-in or document-level customization will do both of these – it extends the user interface, and when the user operates the user interface, it manipulates the open document in some fashion.

In the next post, I'm going to discuss some of the notable points about Office development using VSTO, and compare that to more conventional C# / VB.NET development.