Using Microsoft.Office.Interop.Outlook to get Outlook app and get MAPI Namespace fails - visual-studio-2010

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

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:
Unable to cast COM object of type Microsoft.Office.Interop.Outlook
Outlook issue - Unable to cast COM object of type 'Microsoft.Office.Interop.Outlook.ApplicationClass'

Related

UIPATH - Send Outlook Mail (Unable to cast COM object)

I want to set up a robot able to send e-mails thank's to the UIPATH activity "Send Outlook Mail".
but a receive this error message :
Send Outlook Mail Message: 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: Interface not registered (Exception from HRESULT: 0x80040155).
Some people on internet seem to have managed to correct this problem due to the versioning of Outlook. But my problem seems different because I only have the versions 8.7 listed in the IID : HKEY_CLASSES_ROOT\TypeLib{00020905-0000-0000-C000-000000000046}
It seems your windows registry records are messed. Try to "repair" your Microsoft Office installation. Go to Programs and Features, select Modify and then Repair Online.
This is a widely spread issue when dealing with COM libraries. Here is what the Error: Unable to cast COM object of type 'Microsoft.Office.Interop.Outlook.ApplicationClass' to interface type 'Microsoft.Office.Interop.Outlook._Application'. forum thread states:
Sounds like you have a problem with your typelib registration. Presumably, the Com interop layer is hitting the registry to try to locate the typelib. It would start by looking under HKCR\Interface{00063001-0000-0000-C000-000000000046}\Typelib. The default value should refer to the guid for the typelib that defines the interface in question: which should be located under the following key: HKCR\Typelib{00062FFF-0000-0000-C000-000000000046}. There should be a version subkey and then a 0 subkey, and a win32 subkey under that. The default value of the win32 key should point to the typelib (which is msoutl.olb).
I'd recommend checking your Office directory for msoutl.olb. If it is there, try running 'regtlib msoutl.olb'. You should have regtlib on your machine is part of your Visual Studio install, I believe. Anyway, reregistering the typelib will rewrite all of the necessary keys to the registry. You will need administrative privileges for this operation.
Also you may find the Outlook issue - Unable to cast COM object of type 'Microsoft.Office.Interop.Outlook.ApplicationClass' page helpful.

ADODB.Connection in VB6 - Open Method fails with Runtime Error '2147221164 (80040154)'

This is something that start to happen on a project on which I am working, and so far I was not able to figure out the root cause.
This stopped working without any change from my side, the only thing I know has changed since the last time I worked on that project is that a disk failed (used to be the E: drive on which some applications were installed).
Operative System is Windows Server 2003.
Below the error:
Runtime Error
The Libraries I am adding to the project are the following:
Visual Basic For Applications
Visual Basic runtime objects and procedures
Visual Basic objects and procedures
OLE Automation
Microsoft CDO for Windows 2000 Library
Microsoft Scripting Runtime
Windows Scripting Host Object Model
Microsoft Data Binding Collection VB6 (SP4)
Microsoft ActiveX Data Objecrs 2.8 Library
The object oConn is declared and instantiated the following way:
Dim oConn AS ADODB.Connection
Set oConn = New ADODB.Connection
No reference is marked as MISSING in the VB Project.
I also tried the late binding, but without success. I tried to use regsrv32.exe to reregister msado15.dll, but no joy.
I am really out of idea here, I think that some dependencies are no longer satisfied due to the failure of the disk, but I don't know how to investigate this given the few details provided by the IDE.
Thanks
This question has no easy answer. What I found, and has been also suggested in the comment by #Jim Hewitt, is that MDAC on Windows Server 2003 was corrupted. The component checker is not actually able to identify the version of MDAC, which is an embedded component in that version of Windows.
So, summarizing, the whole windows installation is corrupted (no idea on how this could have happened) and Visual Basic 6 doesn't work properly. The solution has been to setup another machine.

zeromq: "External component has thrown an exception" at the time of creation of new Context - on one particular system

I am using 0mq with clr binding - version 3.2.2 - on Windows OS. On one particular Windows 7 64-bit system, 0mq always fails at the time of creation of a new Context. I initially thought it had something to do with windows services / IIS but it fails even for a simple console application
Error message below
Assertion failed: Connection timed out (..\..\..\signaler.cpp:260)
External component has thrown an exception.
Last error code (I am calling GetLastError from C#) is 10060 (which is connection tiemout)
Code below
var ctx = new Context(1);
I have checked the following links and tried the suggestions but no luck
http://grokbase.com/t/zeromq/zeromq-dev/126jmgg0aq/sehexception-when-calling-zmq-init-from-clrzmq
https://github.com/zeromq/clrzmq/issues/81
Calling Win32 CreateEvent() fails from an IIS 7.5 web application
I have tried the following
Used dependencychecker and ensured all referenced DLLs are present
Ensured VC++ 2010 runtime is installed
The account under which the console application ran has administrator privileges and I also gave explicit permissions to create global objects (one of the suggestions) in user account management
I am baffled by this bug. 0mq has worked great so far and I wanted to deploy it on a larger scale. Now this error is giving me second thoughts on the same. Any help will be greatly appreciated
It looks to me like your app isn't finding the appropriate ZMQ DLL. A couple things to check:
Make sure that libzmq.dll is in the same directory as your exe.
Make sure that you know whether libzmq.dll is 32 or 64 bit.
Make sure that you've explicitly specified an architecture in your C# Project File (either x86 or x64, not AnyCPU), and that the architecture you pick matches the architecture of the libzmq.dll file you're using.

How to invoke a 32bit COM interop dll from VS 2010 Solution which is targetting 64 bit machines

I am working on Windows client application using c#, have two projects in my VS 2010 solution, the start-up project and a class library which uses third party COM interop DLL.My desktop is 64 bit and all the client machines are 64 bit as well.
If I keep the start-up project as any cpu in (build settings) and x86 for the second project which invokes the COM DLL, I am getting the following error:
Could not load file or assembly ... or one of its dependencies. An attempt was made load a program with an incorrect format.
If I keep both the projects as Any cpu, I am getting the following error:
Retrieving the COM class factory for component with CLSID .. failed due to the following error:
Any idea how to resolve the issue without converting the solution (all projects) to x86.
Well, I suggest you to look at DLL surrogates. This trick will definitely solve your problem, but only as long as you may change the registration info of the DLL inrpoc server in the registry.
If the class is configured to use a surrogate, it will run in a separate process. COM allows one to use an out-of-proc 32bit COM server from a 64bit application.
All you need to change is shown below:
Look at the following entry in the registry:
HKCR\CLSID\{CLSID_CoClass}
And look if it has the AppID field. If it does, just visit this registry key:
HKLM\Software\Classes\AppID\{APPID}
and add the DllSurrogate string key with no value.
If the class doesn't have an assosiated AppID, you may create it yourself. Then you may use your 32 -bit inproc library from the 64bit targeted .net application.
Probably the easiest thing to do is just set your main executable to be x86. Its the application that will determine how the rest of the assemblies are jitted.
None of the above worked for me. BUT what you can do is when you click 'Add Reference' select the relevant reference via the COM tab rather than browsing to the DLL. This makes it version specific, so if you select 32 bit version, runtime will go with that. Also, be sure you have selected relevant .NET framework version for application pool and you may want to set 'Enable 32 Bit Application' to true (advanced application pool settings).

System Error &H80004015 (-2147467243). The class is configured to run as a security id different from the caller

When try to debug the VB dll Using Visual Studio 6.0 , I am getting the the following error. Can you any one tell me what needs to be done for this?
System Error &H80004015 (-2147467243).
The class is configured to run as a
security id different from the caller
I have had the same problem.
Created a few ActiveX DLLs and put the binaries into a COM+ Application, which runs under a specific account (not mine). Then I use these components inside ASP script pages using Server.CreateObject().
If I load the source code into VB for debugging and try to run it ("Start with Full Compile") I get this error message.
The cause of this is that the account registered in the COM+ Application differs from my own account from which I try to run.
Solution for this particular case is to Shutdown the COM+ Application and remove the components. When finished debugging, compile the set of DLLs and put them back to the COM+ application.
Hope someone is helped by this :-)
My solution was to unreference the dll in the Visual Basic project (Project Menu -> References), close the dialog box and reference it once again. I ran the project and everything is working again. I did not have to edit the windows registry.
There's a knowledge base article that seems to apply to your situation:
PRB: System Error Message "&H80004015" When You Run ActiveX DLL in Visual Basic IDE
Cause: When Visual Basic runs an ActiveX DLL from the IDE, it calls the CoRegisterClassObject application programming interface (API) to temporarily register the server. This creates the AppId and specifies it to run in the Interactive User context.
This problem occurs because of a bug in the Microsoft OLE Libraries 4.0, which are included with the Microsoft Platform Software Development Kit (SDK). CoRegisterClassObject fails with the error message that is listed in the "Symptoms" section of this article under the following conditions:
If the ActiveX server that calls the API is set to run by using the Interactive User identity.
-and-
The string that is associated with the following registry key contains any value other than a single valid executable name for the shell process:
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon Shell=
Under Microsoft Windows 2000, this error occurs when the Certification Authority service does not start.
Resolution: Make sure that the HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon Shell= registry key contains a single valid executable name for the shell process.
To resolve this problem under Windows 2000, you can install the "Client for Microsoft Network" component and then reboot.

Resources