Most power users of Outlook are aware that it can be customized to a degree. The ability to create custom forms or use VBA macros have been around since Outlook 97 and Outlook 2000, respectively. Even casual users know that COM Add-ins can be built and installed to “add-on” functionality to Outlook which doesn’t exist. So if you’re thinking of becoming an Outlook programmer or are just curious as to what can be done, here’s a summary of the development tools that can be used.
As stated, custom forms and VBA macros are common ways to design new interfaces or program with Outlook – and these are tools available “out of the box”. However, VBA solutions are typically used to automate simple tasks and don’t offer a proper deployment mechanism to install for multiple users. Similarly, traditional custom forms with legacy VBScript code is really a technology well-past its prime. Neither approach is suitable for professional solutions.
So how is a truly professional Outlook solution designed? The most powerful approach available for programmers is to build a COM Add-in. Add-ins allow you to build complex and highly interactive Windows Forms applications using many programming languages and powerful code editors. Add-ins can also be easily deployed for many users using Windows Installer packages or with Click-Once from the web.
For hard-core solutions, the top choice is to build a COM Add-in with Visual C++ using Extended MAPI (Messaging Application Programming Interface). What is MAPI, you may ask? Essentially, it’s the master list of all instructions and commands available for talking to Outlook. Aye, but there’s the rub: good C++ developers are hard to find, as it’s a very complicated language. And the Outlook interfaces in MAPI are extraordinarily complex and require a steep learning curve to understand.
Thankfully, the Outlook Object Model (OOM) is also available for developers. Serving as a “wrapper” layer to talk to MAPI, OOM is far easier to understand and exposes the majority of the objects, events, properties and methods for programmers to use to talk Outlook into doing the crazy things we ask it to do. Those of you familiar with VBA know that your code is using OOM, and it’s also used by VBScript in custom forms. Yet the problem with OOM is that it trades in full access to MAPI for ease of use. Thankfully, there are tools available to fill in these gaps, which we’ll discuss later in Part 2.
Creating COM Add-ins is most commonly done with Visual Studio. Shared Add-ins – named because they can be built to run in any Office application – have been built since Visual Studio 6.0 using Visual Basic 6, and can still be built with Visual Studio 2010. However, these types of add-ins require a lot of additional code to distinguish which application is calling your add-in.
The preferred approach is to use Visual Studio Tools for Office to build a COM Add-in. VSTO was available as a separate install for older versions of Visual Studio but is now built-in to Visual Studio 2010. VSTO provides additional programming shortcuts and useful objects not available in Shared Add-ins. It also has handy designers, wizards and interfaces for customizing the Ribbon, creating Form Regions or implementing custom Task Panes. You still of course have the ability to automate OOM with your VB.NET or C# code, but MAPI is not officially supported.
Next week we’ll take a look at another way of building add-ins, and what other tools are out there for an Outlook developer’s toolbox.
More Information
Articles that may interest you:
Last reviewed on Sep 14, 2011
Hot Topics