VSTO add-ins and the NewInspector Event

VSTO add-ins for Outlook are great. It's much easier than implementing the IDTExtensibility2 interface. Basically, the way it works is this (actually, Andrew Whitechapel does a much better job explaining than I will, so here you go): the AddinLoader.dll keeps a "dormant" list of add-ins that tried to load when the Outlook.exe process is started.

If there's UI (if there are any Explorers or Inspectors visible), then it fires the _Startup event. If there is no UI (like when using the Outlook View Control or ActiveSync), then it doesn't fire _Startup until the first Inspector or Explorer is made visible. Once the last UI element is closed, then VSTO fires the _Shutdown event.

A typical operation one would usually perform (and a reason for creating an add-in in the first place) is to add some sort of UI to an Inspector or Explorer, such as a button on a command bar or a menu item. In a traditional COM add-in, the way you would do this would be to hook in to the Inspectors.NewInspector event and in the handler for that event, you'd add your UI. And that works great. It works great in VSTO also, except the first time.

Because VSTO itself is waiting until the NewInspector event fires (in scenarios where Outlook.exe is started with no UI) to fire the _Startup event on your VSTO add-in, it is too late to bind to the event yourself (it's already been fired). So what happens is that the first time an Inspector opens, your button is not added to the CommandBar, but the second time it is!

The way to get around this problem is simple. Remember that the _Startup event is fired during the NewInspector event. So in your _Startup code, just check the Inspectors.Count property and if it's greater than 0, go ahead and add your button (or whatever)! In subsequent calls to the NewInspector, your code will fire.

Here's an example:

private Microsoft.Office.Interop.Outlook.Inspectors objInspectors;

private void ThisApplication_Startup(object sender, System.EventArgs e)
   objInspectors = this.Inspectors;
   objInspectors.NewInspector += new Microsoft.Office.Interop.Outlook.InspectorsEvents_NewInspectorEventHandler(objInspectors_NewInspector);
   if(objInspectors.Count >= 1)

private void ThisApplication_Shutdown(object sender, System.EventArgs e) {


private void objInspectors_NewInspector(Microsoft.Office.Interop.Outlook.Inspector Inspector){

private void AddCustomUI(){
      //...do your add button thing or whatever here

Comments (28)
  1. Raj Pamamull says:

    Hi Patrick, I’ve built a VSTO addin for Outlook 2003 (SP1) with VS2005. The add-in works fine when Outlook is opened normally but when Outlook is opened without its UI the addin is disabled (loadbehaviour=2). Thing is, it’s disabled before it gets to the startup event.

  2. pcreehan1 says:

    Changing the LoadBehavior to 2 is not disabling your add-in, it’s "disconnecting" it. There’s a slight, but significant difference. Your add-in was, what we call, "Soft disabled," which means there was a problem loading your add-in which crashed your add-in. It was not a significant enough problem to crash Outlook.exe so it wasn’t "hard disabled" in which case your LoadBehavior would be set to 0 and it would appear in the Disabled Items dialog box.

    My guess is that you have some member level code or something that is assuming the presense of an explorer window being present. Remember that your add-in’s startup event is not fired until the first explorer or inspector window is created. When outlook is loaded without UI, you have neither. If you read Andrew Whitechapel’s blog I linked to above, this is explained clearly.

    Try commenting out all your code so you just have an empty stubbed out frame of a VSTO add-in and add back in until you get it to break. My guess is you’re assuming UI elements where there are none.

  3. Raj Pamamull says:

    Thanks Patrick, I created a new Outlook add-in with no code in the startup event and this also gets "disconnected". Specifically the Outlook Addin gets disconnected if Outlook is automated via the "File -> Send To -> Mail Recipient" function of other Office applications (i.e. Word).

    My originally addin checked the Explorer count and is also error handled. Also, with the new add-in I’ve experimented with MessageBoxes in different parts of the addin and these never get called, so I don’t think the start up event is reached.

  4. pcreehan1 says:

    Ok, so using the Send To Mail Recipient link is a little different than how I understood your original question. That link actually uses a Simple MAPI call to create a new mail message (which your default happens to be Outlook). Since your MAPI form provider happens to be Outlook, an Outlook MAPI form is created. But since it wasn’t Outlook that created the inspector, Outlook doesn’t keep track of that inspector, so the inspector count is still 0. Outlook.exe does start and the add-in keys are enumerated and manifests are loaded, but Startup is not called until Outlook registers a UI element being created.

    I created a simple VSTO addin to try to repro your issue, and mine was only soft disabled when I tried to do something outside the startup event (like in the Initiate method).

    Again, my guess is that if you created a brand new VSTO add-in with no code in it, it would not get soft disabled. You can then slowly add back your code until you discover what’s causing the soft disable.

  5. Raj Pamamull says:

    Hi Patrick, I only added the messageboxes to my newly created add-in after it still got soft disabled. But before this it had no code in it.

    ( only the vs generated stuff, i.e. ThisAddIn_Startup, ThisAddin_Shutdown, InternalStartup and ThisAddIn.Designer.cs )

    Just to confirm, on the basis of the simple add-in you created a “blank” outlook addin shouldn’t be disabled in this situation and the startup event should be reached?

    Could it be something else other than the code – I’m using VSTOR (SE), Outlook2003, Office 2003 SP1, Office 2003 Interop Assemblies, built with VS2005


    -The default mail editor of Outlook is WordMail

    -The add-in only gets disabled if Outlook isn’t already opened when the Send To Mail Recipient link is hit

    -I’ve rolled this add-in out to 30+ users and they all have the same issue (so it’s not isolated to my computer)

    -All other Outlook add-ins on my computer have been disabled

  6. pcreehan1 says:

    So, yes, I created a new VSTO 2005 (not SE but that shouldn’t matter) add-in which had no code in it except messageboxes in the Startup and Shutdown events. My add-in was not soft disabled when using the Send To Mail Recipient menu item from Word.

    I assume you built the add-in with VSTO 2005 SE since you have the VSTO 2005 SE Runtime.

    It could absolutely be something other than the code, but that’s hard to tell in this medium. If you open a support case (http://www.microsoft.com/services/microsoftservices/srv_support.mspx) with us, we could look at it.

    You may want to consider taking a ProcMon trace (http://www.microsoft.com/technet/sysinternals/FileAndDisk/processmonitor.mspx) and seeing if you can see what’s happening around the time it flips your LoadBehavior key.

  7. Raj Pamamull says:

    Thanks Patrick,

    I’ll submit a support case for this.

    I ran the ProcMon trace – it told me that the addin gets soft disabled right after it hits the dll manifest file.

    Also, am I able to download your VSTO version – it’d be a good test to see whether using your version would resolve this?

  8. Raj Pamamull says:

    Where should I log the support case?

    The company I work is a member of Microsoft Premier Support

  9. pcreehan1 says:

    My group is called "EBA Messaging Dev". If you just go through your normal channels of opening a case. Tell the tech router that you have an add-in for Outlook that is breaking and that you spoke to an engineer from "EBA Messaging Dev" and that he said his team would support you, they can route you to the right group.

  10. pcreehan1 says:

    So it seems that using VSTO 2005 SE <i>does</i> matter. It may be an untested scenario to automate Outlook 2003 with VSTO 2005 SE add-ins.  I do not reproduce the same behavior with VSTO 2005 (not SE) runtime.

  11. Chris says:

    Thanks.  I was having the same problem and this is at least a good explanation.

  12. Is this issue solved? If so what is the solution?

    A request to solve this is currently posted in the VSTO forums:



    -= Maarten =-

    MVP – Visual Developer – VSTO

  13. (Re-posting here my reply to http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1413814&SiteID=1


    We (the product team) have confirmed that Outlook 2003 will be soft-disabled in headless mode and this is a bug in VSTO 2005 SE. We do have a fix which is currently is beta-tested but is not yet widely released to the public.

    There are currently no workarounds for this issue. Moving to Outlook 2007 will solve the problem – but for majority of our users this is hardly feasible.

    The only thing I can say at this point is that I will make an announcement on my blog (http://blogs.msdn.com/mshneer) when the update is released. Sorry for being the bearer of bad news.


  14. pcreehan1 says:

    Thanks Misha. Again, to reiterate, this is ONLY a problem with VSTO 2005 SE on Outlook 2003. Using VSTO 2005 on Outlook 2003 does not have this problem. Also, using Outlook 2007 will help you avoid this issue as well.

    If you are a Premier or Professional level customer experiencing this behavior, open a support case with Microsoft and ask to be directed to the “EBA Messaging Dev” team. We have several cases on this waiting for the fix, which may still be several months from release. Watch Misha’s blog for more information regarding the release of that patch: http://blogs.msdn.com/mshneer

  15. pcreehan1 says:

    Just as an update to those of you watching this thread, the hotfix for VSTO should be released sometime in the next couple months. It will include several fixes including a new one just added where StickyNotes do not close in Outlook 2003 on the first click of the X.

  16. Raj Pamamull says:

    Hi Patrick,

    Is VSTO 2005 still available for download I can’t seem to find it? MS supplied us with a new Addinloader.dll which fixed the Outlook problem although we also have VSTO word templates that are really unstable. We deployed the solution out to about 1000 users and about 50% of these users have complained about various errors – primarily corrupted document errors and a menubar on the main menu only functioning 80% of the time.

    A developer I know from Avanade said that VSTO2005 from his experience is much more stable than SE. Is this the case and if Microsoft can confirm this I think my customer would pay for us to redevelop the solution in the first edition.

    This customer is basically at the point where he wants to move back to VBA as at least it’ll be more stable. P.S. they can’t move to Office 2007 for at least 12 months.


  17. pcreehan1 says:

    Raj – So, the VSTO 2005 RTM runtime is no longer available for download nor is it supported. It has been replaced by the VSTO 2005 SE runtime. You can still develop VSTO 2005 RTM add-ins with the VSTO 2005 RTM <i>designtime</i>, but they will run on the VSTO 2005 SE <i>runtime</i>. I know that’s as clear as mud, but that’s how it is. The VSTO 2005 SE runtime does have a few problems, as indicated in this thread, but the Cypress GDR patch should resolve several of them. The Cypress GDR patch should be released in the next couple months.

    Remember the VBA is not redistributable so that would not be a good deployment experience for your customer. I would suggest sticking with your VSTO 2005 SE development and just keep working out the bugs. Happy coding!

  18. Raj Pamamull says:

    Thanks Patrick,

    Would you be able to provide the list of fixes that the Cypress GDR provides?

    The document corruption issues are related to users saving VSTO documents to fileshares that don’t have .NET Security Policies associated with them. I had to develop a utility to allow the users to manage these security policies themselves. But I didn’t really like the idea of doing this to be honest.

    In relation to the menubar I should have actually said commandbarpopup. Here is the code related to this within my VSTO Word add-in:

    Office.CommandBarPopup menuPopup;

           Office.CommandBarButton btnLetterhead, btnAgenda, btnFax, btnMemo, btnMinutes, btnFilenote, btnProposal;

    // Create the Templates menu

               menuPopup = (Office.CommandBarPopup)this.Application.CommandBars.ActiveMenuBar.Controls.Add(Office.MsoControlType.msoControlPopup, missing, missing, missing, false);

               menuPopup.Caption = “Templates”;

               menuPopup.Tag = “Templates”;

               // Adds the Letterhead menu item

               btnLetterhead = (Office.CommandBarButton)menuPopup.Controls.Add(

               Office.MsoControlType.msoControlButton, missing, missing, missing, false);

               btnLetterhead.Caption = “Letterhead”;

               btnLetterhead.Tag = “McN.Letterhead”;

               btnLetterhead.Click += new Office._CommandBarButtonEvents_ClickEventHandler(btnLetterhead_Click);

    // and so on for each menuitem

    Do you see any reason why the commandbarpopup for this add-in would be unstable? Please note these users have other add-ins installed that create commandbarpopups as well (i.e. Adobe add-in)

    Last thing – when you load up a VSTO document for the first time it’s like starting up an ASP.NET application session for the first time (it’s very slow). Sometimes the wait is up to 10 seconds. This isn’t really good enough for this customer or any customer – is there a work around for this?

  19. pcreehan1 says:

    I’m not an expert on VSTO when used with Word – my expertise is with messaging development, so I’m more familiar with Outlook. I’m not sure what you mean by "unstable" so it’s difficult to answer your question. I would want to make sure that your commandbar object as well as each button you are creating is defined as a class level member and not inside of a function. As soon as GC runs, your reference will be destroyed and your callbacks won’t be…called back.

    As far as documenting the fixes in Cyrpress GDR, I’m sure that the fixes will be documented when it is released.

    With regards to VSTO taking a while to start up, this is the same for any .NET code that is JITted. You need to wait for the framework to load and for your assemblies to be JITTEd. If performance is a key requirement, then you may want to look into building native images of your dlls. You may also want to limit the amount you are doing in the Startup event.

  20. Kulvinder says:


    Anybody has any idea when this Holy Cypress GDR patch will be released ?

  21. pcreehan1 says:

    Here are the fixes included in this release


  22. David Lockie says:

    My add-in still doesn’t load if ActiveSync or Send To –> Mail Recipient is used before openig Outlook with a UI.  I’m using VSTO 2005SE and Outlook 2003.

    I’ve downloaded the update but stil no joy.  My toolbar is on the explorer not the inspector.

  23. pcreehan1 says:

    Are you saying that when you use Send To > Mail Recipient (or ActiveSync) and then open up Outlook’s UI, your VSTO 2005 SE addin which adds a toolbar to the explorer doesn’t work?

    Remember that Send To > Mail Recipient is a Simple MAPI call that will launch a new mail item modally. When these windows are launched modally, Outlook events don’t fire, so you’ll never get your VSTO add-ins to load during this call. What the update addressed was a bug where doing Send To > Mail Recipient would soft disable your add-in.

    Are you adding the toolbar in the Startup event or are you waiting for new explorers (NewExplorer event) to be generated? If Outlook was launched with no UI, then VSTO won’t load your add-in until it detects UI, so the Startup event is too early to add a toolbar to an explorer window. If you need further assistance, I’d suggest opening a support case.

  24. Japan Shah says:


    is there any way to fetch the email thats being sent from Outlook without opening outlook, so what I want is when new message is opened up without opening outlook e.g. from mailto:shahjapan@gmail.com is clicked,

    and when user click on the sent button by default it will be stored in the outlook’s outbox folder, but when user click on the send email I need to do something but here outlook UI is not loaded as only outlook’s new email messege is opened.


    japan Shah

  25. Aravind Ramachandran says:

    Is there any update or fix for the VSTO events not firing when the user right clicks on Windows Explorer and choose “Send To Mail Recipient”?  We have an add-in that is created on a “NewInspector Event” which is registered for during ThisApplication_Statup.  But it does not work when the user does the “Send to Mail Recipient” function.  Any workarounds?

  26. pcreehan1 says:

    Hi Aravind,

    As I mentioned earlier, Simple MAPI causes Outlook to open modally. This prevents some of the Outlook events to fire which VSTO is listening to. VSTO is never informed there is new UI and therefore, the _Startup event won’t fire.


    The best workaround I can offer is to do as the article above suggests and create an add-in for your other Office apps which remove the the Send To > Mail Recipient menu item and replace with your own code which automates Outlook directly (instead of using Simple MAPI).

  27. Haja says:

    I am having a Addin in my Outlook, which is working great (developed by C#). Now I am trying to run this addin, when user clicking send mail button on composing new mail in Outlook 2007.

    Anyone has any idea please advise me.

    Thanks in advance


    //——-Ribbon.xml file—-

    <customUI xmlns="http://schemas.microsoft.com/office/2006/01/customui&quot;  onLoad="OnLoad" >



    <tab idMso="TabNewMailMessage">

    <group id="Email" label="Email">

    <button id="toggleButton1" size="large" label="Upload"

    screentip="Create a new ticket" onAction="OnToggleButton1"

    imageMso="HappyFace" />



Comments are closed.

Skip to main content