Troubleshooting Outlook Form Regions

Recently I had to debug a strange issue with an Outlook VSTO plugin where the plugin would install smoothly and load correctly but my custom calendar region was not showing as expected.  To complicate matters a little further, I had some clients on 32-bit and some on 64-bit desktop systems so it was not a straightforward install.

You can find the base steps for registering a VSTO add-in here.

Note: An easy check to see if your add-in is automatically loading correctly is to verify that the LoadBehavior key stays at 3.  You can keep the registry open while you load your Office application and refresh to see if it was unloaded.

Outlook Form Regions have an extra step though and depending on the desktop architecture you are on, you’ll need to create the following registry keys as well.

x32

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\Outlook\FormRegions\IPM.Appointment]
"MySuperOutlookPlugin.Plugins.MyCalendarRegion"="=MySuperOutlookPlugin.Plugins"

x64

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\Outlook\FormRegions\IPM.Appointment]
"MySuperOutlookPlugin.Plugins.MyCalendarRegion"="=MySuperOutlookPlugin.Plugins"

Where these values equal,

MySuperOutlookPlugin.Plugins.MyCalendarRegion – is the fully qualified name of your VSTO assembly and class name of the Outlook Region file.

=MySuperOutlookPlugin.Plugins – is the name of your assembly.

Once you have done this, restart Outlook and you will now see the your Outlook Region load appropriately.

Great Software NEEDS Requirements

I think it would be pretty cool to have had some IoT on my keyboard for all the code I have written to tell me how many lines I have written over the years.

But I would love to cross-reference that statistic with how much code I have rewritten based on poor requirements.

How much code I deleted?

How much code I had to update?

How much time was loss?

I generally try to keep to code on this blog but at the core of every great release are the requirements that are built at the beginning, middle and end.  Do a bad job on those and I can guarantee what the end result will be.

When jumping onto a new project or product, the first thing I always do is sit down with the user and the person writing the requirements so I can see how close they are to understanding each other’s visions for what the end product will be.

If they are closely aligned, I know we’ll be in good shape, if they are far apart, I know I have to plan for some additional work on my side to bring them closer together.

As much as developers would like to ignore this part of the process, they can’t.  Well-written requirements are the first step in a successful software delivery.

The developer’s role might not be to write the requirements, but their role is definitely to ensure that everyone has a complete and thorough understanding of the problem everyone is trying to solve as well as ensuring that the requirements stay true to that focus.

I published a Presentation on SlideShare a few years ago on How to Write Great Requirements, the content is as relevant today as it was then.