When using Visual Studio Tools for Office (VSTO), there are three basic approaches to Office development:
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.
- 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.
- Office/SharePoint Building Blocks and Developer Stories
- Overview of Office 2010 Application Development
- Office Application Scenarios
- Understanding the Three Approaches to Office Development using VSTO
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.
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. Read more: Eric White's Blog
- 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. Read more: Eric White's Blog
Posts
0 comments:
Post a Comment