Microsoft Office has traditionally been known as a powerhouse suite of largely standalone applications. With Office 2007, it has evolved into an application framework that exposes most of its functionality for external consumption as COM servers. This allows developers to build custom solutions, and now, with Office 2007, developers can use Office itself as a development platform.
Office works as a development platform, Andrew Whitechapel and John Peltonen write in What You Need to Know about Using Office as a Development Platform, because it simultaneously addresses basic application requirements and offers toolsets and extensibility points on top of that baseline functionality.
The key extensibility points, Whitechapel and Peltonen write in their MSDN article, are the Office object model and loose typing. The latter lets developers build add-ins with host-neutral code. On the plus side, this allows the add-in to run in any application that supports COM add-ins, regardless of the version. On the other hand, developers lose design-time or compile-time support for the specific types involved.
As for object models, the two write:
Office applications have evolved over time and they have very different sets of functionality, so they will inevitably expose different object models. That said, there is some consistency across the apps. The object model is mostly hierarchical, for example, and there is generally an Application object at the root.
The other difference maker, of course, is Visual Studio Tools for Office, or VSTO -- though Whitechapel and Peltonen note that this tool is still evolving.
The ideal toolset, the authors rationalize, would mix the functionality of VSTO, which offers better runtime performance, and shared add-ins, which are more flexible and backward compatible. And Visual Basic for Applications, which VSTO is set to replace, is still a viable option for developers who seek domain-specific solutions.
Despite the kinks and the learning curve, developing with Microsoft Office appears to be a sound decision for today's .NET professionals, Whitechapel and Peltonen conclude. Part of it relates to the platform's rich plumbing and Microsoft's commitment to improving the platform, and part of it stems from the vast base of end users that Office has. Those users demand custom functionality, whether it is controls within Office or applications outside Office, and now it is easier than ever to develop that functionality.
