Outlook VSTO Add-in Session.GetDefaultFolder returns System.__ComObject not MAPIFolder RRS feed

  • Question

  • I have created a standard VSTO Outlook Add-in c# using the template in VS2019.  I added a ribbon and a button in Add-In Tab to initiate run of following code:

                Microsoft.Office.Interop.Outlook.Application outlookApp = Globals.ThisAddIn.Application;
                MAPIFolder inbox = outlookApp.Session.GetDefaultFolder(OlDefaultFolders.olFolderInbox);
                Items items = inbox.Items;

    Variable outlookApp is set to a valid Outlook application object.  However, when the GetDefaultFolder method in next line returns a System.__ComObject to which inbox is given the object.  So why doesn't the GetDefaultFolder method not return a MAPIFolder object?  Or more importantly, why doesn't this cause an exception?

    The exact same code run in a standalone console app works correctly.  GetDefaultFolder returns a MAPIFolder object.  So simply not clear why the console app works and the VSTO add-in fails.

    Any thoughts?

    old geek

    Thursday, June 25, 2020 6:53 PM

All replies

  • All objects from the Outlook object model in .net are represented by the System.__ComObject type. 

    You need to introduce the Namespace object before accessing the default folder:

    Microsoft.Office.Interop.Outlook.Application outlookApp = Globals.ThisAddIn.Application;
    Outlook.Namespace ns = outlookApp.GetNamespace("MAPI")
    Outlook.MAPIFolder inbox = ns.GetDefaultFolder(OlDefaultFolders.olFolderInbox);
    Outlook.Items items = inbox.Items;

    profile for Eugene Astafiev at Stack Overflow, Q&A for professional and enthusiast programmers

    Thursday, June 25, 2020 8:10 PM
  • So I added the NameSpace with this code:

                Application outlookApp = Globals.ThisAddIn.Application;
                NameSpace nameSpace = outlookApp.GetNamespace("MAPI");

                Folders folders = nameSpace.Folders;
                foreach(Folder folder in folders)
                { }

                MAPIFolder inbox = nameSpace.GetDefaultFolder(OlDefaultFolders.olFolderInbox);

    GetNamespace returns a NameSpace object.  The nameSpace.Folders returns a FoldersClass.  Appears to contain only one folder and it is a  System.__ComObject .  GetDefaultFolder again returns a System.__ComObject.  Also doesn't explain why console app with same code works but VSTO doesn't.

    old geek

    Thursday, June 25, 2020 8:54 PM
  • So how exactly does the problem manifest itself? Does an error actually gets thrown? Or you are only wondering why the debugger in VS says System.__ComObject (whcih is perfectly normal)?

    Dmitry Streblechenko (MVP)
    Redemption - what the Outlook
    Object Model should have been
    Version 5.23 is now available!

    Thursday, June 25, 2020 9:10 PM
  • Following lines are:


                Items items = inbox.Items;

                foreach (object objMail in items)

                    var mail = objMail as MailItem;

                    if (objMail is MailItem)

                       ! code to handle the MailItem

      .              }


    Never get a MailItem, always a System.__ComObject, so if statement fails.  I have tried

               var mail = (MailItem) objMail

    But that causes an exception to be thrown.

    In other words, won't convert the object to MailItem

    old geek

    Friday, June 26, 2020 1:35 AM
  • You can have items other than MailItem in the Inbox folder, such as ReportItem, MeetingItem, etc.

    Change the line

    if (objMail is MailItem)


    if (mail  != null)

    Dmitry Streblechenko (MVP)
    Redemption - what the Outlook
    Object Model should have been
    Version 5.5 is now available!

    Friday, June 26, 2020 1:47 AM
  • I have tried that, no difference. While there a few non-MailItems out of the over 7,000, but using the existing code as well as your suggestion, the present code never returns a MailItem object.  Not one.  None of the MailItem Items in the list are ever found, always being a System.__ComObject.

    The VSTO add-in is running in Office 2016 (Office 65).  The Interop show VS2013 or above, but is that true.

    What is most confusing to me is that the console app that appears to use the PIA library run successfully, using any of the different code options to convert from the System.__ComObject to the MailItem.  In other words, I get MailItems and thus the "Is Mail" check succeeds over 7,000 times.

    old geek

    • Edited by tgueth Friday, June 26, 2020 12:06 PM
    Friday, June 26, 2020 2:46 AM
  • It seems your windows registry records were corrupted. I'd recommend repairing your Office applications (Outlook). 

    profile for Eugene Astafiev at Stack Overflow, Q&A for professional and enthusiast programmers

    Friday, June 26, 2020 1:15 PM
  • I have done the repair previously, no change.  I have checked the registry entries as best I can and not issues there that I can see.  Is there an article or somewhere that provides minute details on which registry entries need to be checked.

    But this still doesn't answer why it works as a .NET console app but not an add-in.  Since they both run the same Outlook application, granted one is an add-in loaded by Outlook and other is console app that starts/communicates with Outlook to get the emails, isn't the same libraries/PIA code being run?  To me, if one works, the other should.

    I do note that the console app doesn't have all the library references as the the VSTO add-in does.  But don't at the moment understand why that would make a difference since the Ribbon class doesn't reference them.

    old geek

    Friday, June 26, 2020 1:34 PM
  • Do they use the same target .net framework version?

    profile for Eugene Astafiev at Stack Overflow, Q&A for professional and enthusiast programmers

    Tuesday, June 30, 2020 1:16 PM
  • Now that is something I have been wondering also. 

    My dev computer is 64-bit Windows 10 but with 32-bit Office 365 Outlook.  I have compiled both as 32-bit and Any CPU with the same results (if I remember correctly, need to retest tonight).  I have tried .Net 4.7.2 and .Net 4.6.2, but again same results but I will retest tonight.

    Since a development system, multiple versions of .Net installed.

    old geek

    Tuesday, June 30, 2020 1:42 PM