In 2002 the first release of Visual Studio .NET and the .NET Framework was nearing completion. A few of us at Microsoft realized that Office programming was going to
the .NET wave unless we did something about it.
What had come before was Visual Basic for Applications (VBA), a simple development environment integrated into all the Office applications. Each Office application had a rich object model that was accessed via a technology known as COM. Millions of developers identified
as "Office developers" and used VBA and the Office COM object models to do everything from automating repetitive
to creating complete business solutions that leveraged the rich features and
interface of Office. These developers realized that their users were spending their days in Office. By building solutions that ran inside of Office, they not only made their users happy, they were also able to create solutions that did more and cost less by reusing functionality already available in the Office applications.
Unfortunately, because of some limitations of VBA, Office programming was starting to get a bad rap. Solutions developed in VBA by small workgroups or individuals would gain momentum and a professional developer would have to take them over and start supporting them. To a professional developer, the VBA environment felt simple and limited, and of course, it enforced a single language: Visual Basic. VBA embedded code in every customized document, which made it hard to fix
and update solutions because a bug would get replicated in documents across the enterprise. Security weaknesses in the VBA model led to a rash of worms and macro viruses that made
Visual Studio .NET and the .NET Framework provided a way to address all these problems. A huge opportunity existed to not only combine the richness of the new .NET Framework and developer tools with the powerful platform that Office has always provided for developers but to also solve the problems that were plaguing VBA. The result of this realization was Visual Studio Tools for Office (VSTO).
The first version of VSTO was simple, but it accomplished the key goal of letting professional developers use the full power of Visual Studio .NET and the .NET Framework to put code behind Excel 2003 and Word 2003 documents and templates. It let professional developers develop Office solutions in VB.NET and C#. It
the problem of embedded code by linking a document to a .NET assembly instead of embedding it in the document. It also introduced a new security model that used .NET code-access security to prevent worms and macro viruses.
The second version of VSTO, known as VSTO 2005, the version of VSTO covered by this book, is even more ambitious. It
with it functionality never available to the Office developer before, such as data binding and data/view separation, design-time views of Excel and Word documents inside Visual Studio, rich support for Windows Forms controls in the document, the ability to create custom Office task panes, server-side programming support against Officeand that's just scratching the surface. Although the primary target of VSTO is the professional developer, that does not mean that building an Office solution with VSTO is rocket science. VSTO makes it possible to create very rich applications with just a few lines of code.
to put into one place all the information you need to succeed using VSTO to program against Word 2003, Excel 2003, Outlook 2003, and InfoPath 2003. It introduces the Office object models and covers the most commonly used objects in those object models. In addition, this book will help you avoid some pitfalls that result from the COM origins of the Office object models.
This book also provides an insider view of all the rich features of VSTO. We participated in the design and implementation of many of these features. We can therefore speak from the unique perspective of living and
VSTO for the past three
. Programming Office using VSTO is powerful and fun. We hope you enjoy using VSTO as much as we enjoyed writing about it and creating it.