Overview of Office 2010 Application Development

You can use a variety of approaches to extend Microsoft Office 2010.  There are multiple ways to extend each of the Microsoft Office applications’ user interfaces and programmatically work with the underlying documents, spreadsheets, or presentations. The best way to accomplish your desired objective is not always obvious.  This article provides a high-level overview of Office 2010 as a development platform, and lists the Office Developer Building Blocks, which are the technologies that you use to extend Microsoft Office.

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

Blog TOCThis 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

I am a developer relatively new to Office client development.  It often is most useful for me to write about a technology immediately or soon after I learn it – mentioning those aspects which stood out to me, and placing technologies in context to other developer technologies that I’ve used.

When you consider Office development, one of the complicating factors is that Office has been around for many, many years, and the developer approach toward Office development has evolved over those years.  It is pretty amazing that many applications that were written years ago using developer technologies of those days continue to operate correctly with Office 2010.  However, our job as developers is to know what the new developer approaches are, and to migrate from the old to the new.  There are good reasons why the Microsoft Office division releases new developer technologies and de-emphasizes older technologies.  It is a tribute to Office development team’s efforts that many of those old developer technologies still work on Office 2010, but except where absolutely necessary, for new development, we should use the new approaches.  While you should only use the recommended approaches for new development, it is valuable and educational to list every Office developer building block.  This is one of the goals of this series of blog posts.

A Short History of Office Development

WordBasic was introduced to Microsoft Word for Windows and Word for OS/2 in 1989.  I believe that it was the first Microsoft Office technology that enabled developers to manipulate documents programmatically.  A few years after that, Microsoft released Visual Basic for Applications, bringing new capabilities and a more normalized library.  COM-based interfaces followed, bringing Office development to C and Visual Basic.  Visual Studio Tools for Office (which are layered on top of the COM-based interfaces) followed, enabling developers to create managed add-ins.

Visual Basic for Applications (VBA)

Many savvy users use VBA by recording a macro, then using the VBA editor to modify the macros.  This is a purely pragmatic developer experience.  Those users are concerned with getting the job done in as fast a manner as possible.  When using VBA in that fashion, VBA is not so much a development environment as an extended, super-powerful character-based user interface to Office documents.  There are companies that have developed extensive applications that used VBA as a development platform, but modern Office applications use Visual Studio Tools for Office to build managed add-ins.  However, there are scenarios where securely-signed VBA code meets the user’s needs better than any other approach.

Extending Office by using COM

The COM based interfaces for Office automation were real development platforms.  It was possible to build robust applications using COM and ActiveX, but if you used COM incorrectly, it was possible to build applications that were NOT robust, to say the least.  There were a variety of problems caused by multiple versions of dynamic link libraries.  This approach to application development was not for the faint of heart, but a detail-oriented developer could put together some cool functionality.  If you were a software vendor who built products that provided significant value on top of the Office applications, you could build great products, but the developers on your staff needed to be top-notch.

Managed Add-Ins using Visual Studio Tools for Office (VSTO)

The release of Visual Studio Tools for Office (VSTO), along with the Primary Interoperability Assemblies (PIA) significantly made it easier to develop.  The PIAs are specially coded .NET assemblies that provide a managed class library that wraps the underlying COM interfaces.  It is so much easier to build robust C# and VB.NET application than applications written in C / C++ using COM.  In development, frictional issues are those that you must deal with due to the underlying platform.  They add no value to your application, but are necessary for developing reliable software.  I’ve developed using both C / COM and C# / VB.NET, and can attest that when developing C / COM applications, you spend more time dealing with frictional issues than you spend when developing using the .NET languages.  When you build an add-in for Office using VSTO, it is called a managed add-in.  I will examine managed add-ins in more detail after I describe what an Office application is.

Note: VSTO has been around since Visual Studio 2003 for document-level projects.  There were two versions of VSTO for Visual Studio 2005: VSTO 2005 and VSTO 2005 SE.  See Features Available by Product Combination for the differences in features.  See this topic for the features in Visual Studio 2008, and this topic for features in Visual Studio 2010.

What is an Office Application

To summarize, Office 2010 consists of a number of applications (in alphabetical order, Access, Excel, InfoPath, Lync, OneNote, Outlook, PowerPoint, Project, Visio, Word), each of which can be extended in specific ways.

Typically, an Office application uses a back-end system that enables collaboration between users or richer interaction with documents, spreadsheets, and presentations.  An application could connect to a high-performance installation of SQL Server or to web services; your managed add-in saves and retrieves data from the SQL server or the web services.  Alternatively, an Office application can be an extension of an existing line-of-business system – pulling data from that system, and generating documents or spreadsheets based on information stored in that line-of-business system.

With the release of Office 2010 and SharePoint 2010, the most effective way to enable collaboration for users of your Office application is to base the application on SharePoint 2010.  SharePoint 2010’s integration with the Office client makes it easier to build features and implement scenarios that make it seamless to operate your Office application from either the Office client or from a browser.

In a separate article, SharePoint Developer Building Blocks: Technologies for Creating SharePoint Applications, I enumerate the developer building blocks for SharePoint 2010.  Using the SharePoint developer building blocks in combination with the Office developer building blocks provides developers with a powerful set of tools for building enterprise applications.

In the next post, I'm going to examine Office development scenarios.