When using Visual Studio Tools for Office (VSTO), there are three basic approaches to Office development:
This blog is inactive.New blog: EricWhite.com/blogBlog 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.
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.
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:
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.