Outlook 2007 Addin Startup Crash due when Outlook startup trigger via Send Mail option on Word or Excel

Question

Having started development on a Outlook 2007 Addin at my new job, a user encountered the following error: Object reference not set to an instance of an object during Outlook startup. After trying to track the issue via additional try catches as the initial VSTO exception message from the unsuppressed alerting was not particularly useful. I tracked the issue to the method that starts with this code:

if (newToolBar == null)
{
    Office.CommandBars cmdBars = this.Application.ActiveExplorer().CommandBars;
    newToolBar = cmdBars.Add("Data Team Toolbar", Office.MsoBarPosition.msoBarTop, false, true);
}

Being relatively new to VSTO, my first assumption was that ActiveExplorer().CommandBars was returning null. After further correspondence, with my end user I was able to confirm that they had started Outlook using Excel's Send mail option from the mail menu. (not a scenario I had foreseen at all.) This seemed to collaborate my theory of the main Outlook window not being open at time, and I was able to successfully reproduce the crash consistently.

As such I added the following code

if (this.Application.ActiveExplorer() == null )
{
    // If Outlook is opened via some other method ie. send on Excel or Word
    // Kill Addin nicely.
    this.OnShutdown();
}

However, I soon realized when I published this version under UAT (as I cannot seem to find a way to reproduce the issue within Visual Studio (Command Switches (https://support.office.com/en-sg/article/Command-line-switches-for-Microsoft-Office-Outlook-2007-92de9e0b-4f97-42a2-8e02-89c4a8294916) Specifically "/c ipm.note" set as a debug argument seems to have no impact on debug startup process.

That this appears to close Outlook as per this link (VSTO Outlook integration - Outlook shutdown event for synchronization) and not just the Addin as I had thought.

The only solution I have thought of from a design prospective (whilst not ideal) would be a way of disabling the Addin from taking further action under this scenario but allow it to run again under normal startup conditions without user intervention. I'm thinking the logic could be included in a guard clause like so,

if (this.Application.ActiveExplorer().Caption != "Microsoft Outlook")
{
    //Disabling code//
}

But I'm not sure how or if I want to implement this, As my Addin has a lot of dependencies on the toolbar (This solution would mean a lot of very specific guard clauses to check the toolbar existed would need to be added, something I rather avoid if at all possible. Ideally I would like the Addin to be able to detect if it's run under a different approach if opened this way, and only load the Toolbar if and when the main window for Outlook is visible, I already have a background main loop as part of other requirements. So possibly something along the lines of?

if(DataTeamAddin.LoadStyle != "Normal")
{
    if(OutlookMainWindowVisible == true && ToolbarIsNotLoaded == true)
    {
        BeginToolbarSetup();
    }
    else
    {
        //Resume Main Loop
    }
}

However I'm unsure how to go about it? let alone how to test this using automated testing in MSTest, as I cannot even reproduce the issue within my VS2013 IDE?

Eugene Astafiev Eugene Astafiev · Accepted Answer · 2015-03-18T15:07:21

First, Command bars were deprecated. Consider using the Fluent UI instead. You can read more about the new UI in the following series of articles in MSDN:

Second, it is a known case when Outlook is run from other Office applications. Only the inspector window is available. You can subscribe to the NewInspector or InspectorActivate events to be aware that the add-in is run when the Send To command is used.

Outlook 2007 Addin Startup Crash due when Outlook startup trigger via Send Mail option on Word or Excel

2 Answers