Why Office Programming?
The family of Office 2003 applications covered by this book (Excel 2003, Word 2003, Outlook 2003, and InfoPath 2003) represents an attractive platform on which to build solutions. You can customize and extend applications by developing solutions against their object models. By building a solution using the Office System, you can reuse some of the most feature-rich and popular applications available. A solution that analyzes or displays data can take advantage of the formatting, charting, calculation, and analysis features of Excel. A solution that creates documents can use the capability of Word to generate, format, and print documents. A solution that manipulates business information can present it in an Outlook folder or in an InfoPath form. It is far better to reuse the applications that you already know than to build these features from scratch.
Information workers use the Office environment on a daily basis. A solution built using Office can become a seamless part of that environment. Too frequently, users must go to a Web page or some other corporate application to get data that they want to cut and paste into an Excel workbook or a Word document anyway. Many users want to use Outlook as their business information portal. By integrating a solution with Office, you enable users to get the information they need without having to switch to another application.
Office Programming and the Professional Developer
Historically, most Office programming has been done via Visual Basic for Applications (VBA) and the macro recording features built in to some Office applications. Users would record a macro to automate a repetitive task within an Office application. Sometimes the code created by recording a macro would be further modified using VBA and turned into more complicated departmental solutionsoften by users who were not trained as programmers and whose primary job was not programming. These solutions would sometimes make their way up the corporate food chain and get taken over by professional developers and turned into business solutions.
Unfortunately, VBA and its focus on macro recording sometimes resulted in Office solutions that were too limited for corporate and professional developers. It can be difficult for professional developers to make a VBA solution scale to an entire enterprise. VBA solutions were difficult to update after they were deployed. Often, the professional developer wanted to use a language other than VBA to continue to grow the solution. The ease of use of VBA, although a boon to users who were just getting started with coding, felt limiting to the professional developer who desired a richer programming environment.
Why .NET for Office?
The .NET Framework and its associated class libraries, technologies, and languages address many of the concerns that professional developers had with Office development. Today's Office development can be done using Visual Studio 2005, which is a rich programming environment for professional developers. Developers can use .NET languages such as Visual Basic .NET or C#. The PIAs allow .NET code to call the unmanaged object models that Office applications expose. The rich .NET class libraries enable developers to build Office solutions using technologies such as Windows Forms to show user interface (UI) and Web Services to connect to corporate data servers.
Why Visual Studio Tools for Office?
Visual Studio Tools 2005 for Office (VSTO) adds .NET support for Word, Excel, Outlook, and InfoPath programming to Visual Studio. VSTO turns the Word or Excel document being programmed against into a .NET class, replete with data binding support, controls that can be coded against much like a Windows Forms control, and other .NET features. It makes it easy to integrate .NET code into Outlook. It enables developers to put .NET code behind InfoPath forms. Developers can even program against key Office objects without having to traverse the entire Office object model.
How .NET Is It?
This book discusses many new .NET ways of programming against Office applications. However, some aspects of Office programming remain awkward using .NET. Most of these awkward areas are attributable to the fact that the Office object models were designed to work with a technology called COM. Although .NET code can talk to the Office object models via PIAs, the object models sometimes do not feel very .NET-friendly. Furthermore, the Office object models do not always follow the naming conventions or design patterns of classes that were designed for .NET.
In the future, many of the Office object models will likely be redesigned for .NET, and the object models will feel friendlier to a .NET developer. For now, developers must live in a transitional period in which some aspects of Office programming feel like they were designed for .NET, and others aspects do not. This book discusses some of the most difficult problems developers encounter when using .NET with Office and how to work around these problems.