Using 32bit COM object from C# or VBS on Vista 64bit and getting error 80004005
- by alexandroid
I need some mind reading here, since I am trying to do what I do not completely understand.
There is a 32-bit application (electronic trading application called CQG) which provides a COM API for external access. I have sample programs and scripts which access this API from Excel, .NET (C++, VB and C#) and shell VBScript. I have these .NET applications as source code and as compiled executables (32-bit, compiled on Windows XP).
Now I have Windows Vista Home 64-bit which makes my head to spin. Excel examples work just fine (in Excel 2003). Compiled .NET sample executables work as well.
But when I am trying to run .NET C# sample converted to and compiled by Visual Studio C# Expression, or run the VBScript script, I am getting error 80004005 when trying to create an object. Initially the .NET application also gave me 80040154 but then I figured how to make it produce 32-bit code and not 64-bit, so now the errors in C# and VBScript applications are the same. That's all the progress I got for now.
And yes, I tried running 32-bit versions of cscript.exe/WScript from SysWOW64 folder on my VBS, but still the result is the same (80004005).
How to solve this problem? I am almost ready to believe it is practically impossible, but the fact that Excel VBA works and .NET executables compiled on Windows XP run just fine just makes me angry. There should be a way to beat this thing (some secret which probably only Windows Vista developers know)! I will appreciate any help!
PS: I believe code samples do not make much sense here, but this is the line of VBScript which fails:
Set CEL = WScript.CreateObject("CQG.CQGCEL.4.0", "CEL_")
And this is C#:
CQGCEL CEL = new CQGCEL();
Update: Forgot to say UAC is off, of course. And I am working from account with administrator priviledges.
I also tried watching which registry keys are read using Process Monitor but everything looks OK for GUIDs of this object. I could not recognize some other GUIDs so I am not sure whether they were critical or not.
Is there a chance that this COM object uses Internet Explorer and gets the wrong one (like Internet Explorer 7 instead of Internet Explorer 6 engine or something)?
