CODEWITHSUNDEEP
visual-studio-2010outlookcomoffice365
user3461770
user3461770

Reputation: 13

Using Microsoft.Office.Interop.Outlook to get Outlook app and get MAPI Namespace fails

I am attempting to migrate an x86 application that reads MailItems from Outlook.exe running on an old PC (64 bit Windows 7 Ultimate, retail Office x86) to a newer PC (64 bit Windows 10 Pro, Office 365 x86). I am using VS2010 on both PCs. I have "Embed InterOp Types" = TRUE.

The app fails when getting the the Application and Namespace from Outlook (see code and exception below). I have reason to believe that I am not referencing the right Outlook .dll(s) or PIAs. I have searched the web for current information that might apply to my configuration. The best I have found is Cannot add reference to Outlook 2016 (Office 365) Interop (16.0.0.0) The Solution to that question suggests two fixes. "Force the app to x86 or install Office 365 as 64 bit"
The rational is that Visual Studio will only register 64-Bit versions of .dll(s) to the GAC on 64-Bit Windows.
In my case, the app has always been x86 and Office 365 is and must be x86. I use MS Access and Excel VBA Modules and both work as expected with no problem with their referenced .dll(s).
My Question: Which .dll(s) should I be referencing and where can I find them or do I need to DirectCast something?
Details:

The code below is an extract of the problem code. Only the two lines before and following the "Try" actual matter to this question.

    Imports Microsoft.Office.Interop.Outlook
    'Code and Declarations dealing wih GUI and Data structure setup
    ...
    'Called from Form.Shown Handler
    Private Sub GetMessages()
        Dim app As Microsoft.Office.Interop.Outlook.Application = Nothing
        Dim ns As Microsoft.Office.Interop.Outlook.NameSpace = Nothing
        Try
            app = New Application()        'Executes ... but
            ns = app.GetNamespace("MAPI")  'Throws Exception
            ns.Logon(Nothing, Nothing, False, False)
              '....Code to read the MailItems....
        Catch ex As System.Runtime.InteropServices.COMException
            Debug.WriteLine(ex.ToString())
        Finally
            ns = Nothing
            subFolder = Nothing
            inboxFolder = Nothing
            'app.Quit() 'probably not needed
            app = Nothing
        End Try
    End Sub

When run, the above code throws the below exception at the GetNamespace call.
Unable to cast COM object of type 'Microsoft.Office.Interop.Outlook.ApplicationClass' to interface type 'Microsoft.Office.Interop.Outlook._Application'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{00063001-0000-0000-C000-000000000046}' failed due to the following error: Element not found. (Exception from HRESULT: 0x8002802B (TYPE_E_ELEMENTNOTFOUND)).

Of course, my code depends on having the right references. I got to this point by copying the Solution from the old PC to the new PC. I then loaded it into VS2010 and rebuilt it. This Rebuild changed the references to:
Microsoft.Office.Core -- C:\WINDOWS\assembly\GAC_MSIL\Office\15.0.0.0__71e9bce111e9429c\Office.dll
Microsoft.Office.InterOp.Outlook -- C:\WINDOWS\assembly\GAC_MSIL\Microsoft.Office.Interop.Outlook\15.0.0.0__71e9bce111e9429c\Microsoft.Office.Interop.Outlook.dll

Upvotes: 0

Views: 2319

Answers (2)

Joseph 'Joey' Morgan
Joseph 'Joey' Morgan

Reputation: 1

I had a similar problem using code I built on my desktop, but which wouldn't run because of that issue. I used this approach for getting a property that is the application in the main class. It seems to work: First I use aliases to make things easier to read, so XL is set up with the using statement:

 using XL=Microsoft.Office.Interop.Excel;

Then I use the explicit cast to the Application rather than using just "Application" I used (XL.Application

public XL.Application XlApp
    {
        get
        {
            if (xlApp == null)
            {
                xlApp = new XL.Application();
            }

            xlApp.DisplayAlerts = false;
            return xlApp;
        }
        set => xlApp = (XL.Application)value;
    }

I hope this leads to some benefit even if it doesn't completely solve the problem.

Joey

Upvotes: 0

Eugene Astafiev
Eugene Astafiev

Reputation: 49445

Try to "repair" your Microsoft Office installation. Go to Programs and Features, select Modify and then Repair Online. It seems your windows registry keys were messed up. Read more about such issues:

Upvotes: 1

Related Questions