Compartilhar via

Troubleshooting Outlook COM Addins – Using Instrumentation

  • Artigo

At this point, you should have done the following:

  1. Confirmed that COM can create your Addin using VBScript
  2. Confirmed that Outlook is finding your Addin's registration and that the Addin is properly registered with COM
  3. Confirmed that Outlook is loading your DLL into it's process

Since you are confident that Office is at least loading your Addin now you can determine why it's not behaving as expected.

The biggest problem we see with Addins is when the developer assumes that Outlook is in a certain state and that is not always true.  For example it is very common for developers to have code like this:

 m_Explorer = Application.Explorers[1];

However, Outlook does not always have a collection of Explorers.  The user could have double-clicked a .MSG file on his desktop with Outlook closed and therefore won’t have an Explorer.

The above code will result in a NullReferenceException, if you’re lucky your error handling code will catch it, if not the Exception will bubble up to Outlook which will promptly disable your Addin. Now if you haven’t put any error handling code in your Addin or you don’t have instrumentation (such as logging) in your code, the only symptom you will see is that whatever requirement your Addin was supposed to fulfill doesn’t happen.

To combat this I suggest putting in instrumentation code such as logging, extra annoying but effective MessageBoxes or a combination thereof as VSTO does.

This should help you narrow down exactly at what point in your code the error occurs.  The next step is to fix the bug and redeploy.  This concludes the series. I hope it was helpful.

Comments