Building Professional Outlook Applications

VBA macros are not very deployable – copying code amongst desktops is no way to install software. Add-ins are bona fide applications that can be packaged and installed like most professional software, but building them involves a steep learning curve and not being aware of some common pitfalls can turn your brilliant solution into "vaporware" in no time. As such, here are pointers to help get you started, some best practices to use and highlights of helpful resources to keep abreast of.

What You Need To Begin

Add-ins are primary developed using Visual Basic 5.0/6.0 or Visual Studio .NET 2003/2005 (with the Visual Studio Tools for Office, or VSTO), although they can be created using C++ or Delphi. Apocryphal evidence suggests that most add-ins are developed with VB6, but momentum is moving away from that preferred tool towards the more mature VSTO with the new version of Visual Studio .NET 2005. Bottom line – use what you know if you want your solution done quickly, or use the latest and greatest if you have time to learn.

An excellent way to begin is to download a template for VB6 that helps illustrate the basic "plumbing" in VB6 for you ( http://www.microeye.com/resources/template.htm), or use the Add-In template in .NET.

Both templates provides a Connect class that implements the IDTExtensibility2 interface, which allows custom solutions to load inside of Office applications. The class comes with all the event handlers you need all hooked up and ready to go, saving you a lot of work and grief.

All Set, Now What?

I won't get into the nitty gritty details about COM Add-In architecture due to the scope of the material, but these articles, although they appear dated because they reference older Outlook versions in the title, are still valid and are the best documentation available for free:

COM Add-ins Part I: Introducing an Office 2000 Solution for the Entire (Office) Family:
http://msdn.microsoft.com/library/en-us/dno2kta/html/msotrcom.asp

COM Add-ins Part II: Building a COM Add-in for Outlook 2000:
http://msdn.microsoft.com/library/en-us/dno2kta/html/trcomad.asp

How to create a COM Add-in for Outlook 2002:
http://support.microsoft.com/default.aspx?scid=kb;en-us;291163

For .NET, see:

Building Outlook 2002 Add-ins with Visual Basic .NET:
http://msdn.microsoft.com/library/en-us/dnout2k2/html/odc_oladdinvbnet.asp?frame=true

The best compendium of resources on the Internet related to COM Add-Ins is also handily gathered at OutlookCode.com when you need to do further research:

Developing COM Add-ins for Microsoft Outlook:
http://www.outlookcode.com/d/comaddins.htm

So with a template in hand, the best reference material at your fingertips and your brilliant idea ready to be translated into code at your keyboard, there are lots of tricks and traps to keep on top of…

The Biggie…

Be very wary of the Outlook Object Model Guard, introduced way back in Office 2000 Service Pack 2 with the Email Security Update (again, for the full details see Microsoft Outlook "Object Model Guard" Security Issues for Developers: http://www.outlookcode.com/d/sec.htm). If your application is only to be used in an Outlook 2003 environment, you can breathe a sigh of relief. Just make sure to derive ALL your object variables from the Application object passed to the AddinInstance_OnConnection event in the Connect class. This is handled by the COM Add-In template for you by setting that Application object to the global m_olApp variable in the modOutlook module. Also strive not to instantiate any other Outlook.Application objects anywhere else.

If you need to code for all Outlook versions, and you are doing anything that involves sending e-mails automatically, accessing e-mail addresses or working with HTML in the message body – you will get stung by the Object Model Guard. You do NOT want users having to put up with the dreaded "HELL" prompt as it is known. You essentially have no choice but to read and reread the page mention above at OutlookCode.com to find the best solution for you. The best option is to use Redemption ( http://www.dimastr.com), but if you need a free solution and your application will be deployed in an Exchange environment, use the Outlook Administrator Pack (with care, due to the possible security issues).

Best Practices…

Once you've mastered the issue with the Object Model Guard, keep these things in mind and you'll be well on your way to building a professional Outlook application:

• If you want your Add-In to be available for multiple Outlook profiles used on the same computer, it needs to be connected in the registry via HKLM, not HKCU. However, the add-in will no longer be listed in the COM Add-Ins dialog in Outlook, so users essentially can't turn it off. Users will also need Administrator rights to install the add-in as opposed to just Power User for HKCU add-ins.

• Implementing custom command bars or menus can be tricky. You can't just create them once with code and forget about it. They need to be hooked up and closed down properly for every new Outlook or Outlook item window. The best method to do this is to implement Explorer and Inspector wrappers. See the Items Command Bar code sample at Micro Eye ( http://www.microeye.com/resources/itemsCB.htm) for an example using Explorer wrappers, and see Ken Slovak's sample ( http://www.slovaktech.com/code_samples.htm#InspectorWrapper) for Inspectors.

• When writing for multiple Outlook versions, develop using the appropriate Object Model library for the version using the minimum functionality you need. To do this you'll need to copy the MSOUTL9.OLB or MSOUTL.OLB file (Outlook 2000 and 2002 respectively) to your computer and set that as your library reference within the project. If you are using custom command bars or menus, you'll need the MSO9.DLL or MSO.DLL files as well (Office 2000 and 2002).

• If you want to use custom icons with any custom command bar buttons, they cannot be used with Outlook 2000. A whole bunch of different icons are built in to Outlook anyway and can simply be referenced by their ID value with any version. See http://www.outlookexchange.com/articles/toddwalker/BuiltInOLKIcons.asp for handy visual maps of the hundreds that are available.

• Make sure you clean up all your Outlook object variables when you are done with them, and implement error handling in EVERY possible location. Failing to do either can cause your add-in to fail rather ungracefully and could also bring Outlook to its knees.

• Use an installation utility like Visual Studio Installer (free) or third-party ones to package up your DLL and any dependencies for proper setup and removal on your user's computers. Ensure that any Outlook or Office libraries are not included in the file list to prevent version mismatches.

So with all that in mind, you should have plenty to keep you busy – and plenty to keep you on track – as you polish up your Outlook solution for a truly professional user experience.