The return value from CoCreateInstance is COR_E_MEMBERACCESS. I've
looked around the 'net and on MSDN and can't find any info on this.
How would I approach figuring out what is causing that return value?
In other words, does that error code give me some kind of clue about
what to change?
---- Background: -----
The COM DLL is a .NET C-sharp program that begins:
namespace MyNamespace
{
[Guid("822F83B3-644F-4c59-AA2A-7257D0ABE301")]
public interface IManagedInterface
{
bool Configure(string iniPath);
bool Connect();
bool Disconnect();
string GetUpdate();
}
[Guid("0D75D411-AD2F-419c-94EE-91A251ABC41D")]
public class MyClass : IManagedInterface
{
etc....
The calling code is:
::CoInitialize(NULL);
::CoInitializeSecurity(NULL, -1, NULL, NULL, RPC_C_AUTHN_LEVEL_NONE,
RPC_C_IMP_LEVEL_ANONYMOUS, NULL, EOAC_NONE, NULL);
.....
IManagedInterface* pInterface = NULL;
HRESULT hr = CoCreateInstance(CLSID_MyClass,
NULL, CLSCTX_INPROC_SERVER,
IID_IManagedInterface,
reinterpret_cast<void**>(&pInterface ));
I have registered the resulting DLL with REGASM.
The exact same code worked in an earlier release of our product. The
only difference I can see is that the older version was compiled with
MSVC 7.1, and the current release is using MSVC 8.0, also, the version
number of the COM Server was changed.
I can drop the older DLL over the newer one and my app starts working.
As near as I can tell, the code is identical in the two versions and
they were registered the same way.
Thanks for any clues!
BTW, the registry for this item looks like this:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\CLSID\{0D75D411-AD2F-419C-94EE-91A251ABC41D}]
@="MyNamespace.MyClass"
[HKEY_CLASSES_ROOT\CLSID\{0D75D411-AD2F-419C-94EE-91A251ABC41D}
\Implemented Categories]
[HKEY_CLASSES_ROOT\CLSID\{0D75D411-AD2F-419C-94EE-91A251ABC41D}
\Implemented Categories\{62C8FE65-4EBB-45e7-B440-6E39B2CDBF29}]
[HKEY_CLASSES_ROOT\CLSID\{0D75D411-AD2F-419C-94EE-91A251ABC41D}
\InprocServer32]
@="mscoree.dll"
"ThreadingModel"="Both"
"Class"="MyNamespace.MyClass"
"Assembly"="MyNamespace, Version=5.5.1.0, Culture=neutral,
PublicKeyToken=null"
"RuntimeVersion"="v2.0.50727"
"CodeBase"="file:///C:/Program Files/MyProduct/MyNamespace.DLL"
[HKEY_CLASSES_ROOT\CLSID\{0D75D411-AD2F-419C-94EE-91A251ABC41D}
\InprocServer32\5.1.70.2]
"Class"="MyNamespace.MyClass"
"Assembly"="MyNamespace, Version=5.1.70.2, Culture=neutral,
PublicKeyToken=null"
"RuntimeVersion"="v2.0.50727"
"CodeBase"="file:///C:/Program Files/MyProduct/MyNamespace.DLL"
[HKEY_CLASSES_ROOT\CLSID\{0D75D411-AD2F-419C-94EE-91A251ABC41D}
\InprocServer32\5.5.1.0]
"Class"="MyNamespace.MyClass"
"Assembly"="MyNamespace, Version=5.5.1.0, Culture=neutral,
PublicKeyToken=null"
"RuntimeVersion"="v2.0.50727"
"CodeBase"="file:///C:/Program Files/MyProduct/MyNamespace.DLL"
[HKEY_CLASSES_ROOT\CLSID\{0D75D411-AD2F-419C-94EE-91A251ABC41D}
\ProgId]
@="MyNamespace.MyClass"
SvenC - 20 Jun 2007 15:16 GMT
Hi,
> The return value from CoCreateInstance is COR_E_MEMBERACCESS. I've
> looked around the 'net and on MSDN and can't find any info on this.
[quoted text clipped - 4 lines]
>
> ---- Background: -----
<snip/>
>>> CoInitialize(NULL);
>>> CoInitializeSecurity(NULL, -1, NULL, NULL, RPC_C_AUTHN_LEVEL_NONE,
> RPC_C_IMP_LEVEL_ANONYMOUS, NULL, EOAC_NONE, NULL);
Does anything change if you leave out CoInitializeSecurity?
--
SvenC
prose - 20 Jun 2007 19:43 GMT
> >>> CoInitialize(NULL);
> >>> CoInitializeSecurity(NULL, -1, NULL, NULL, RPC_C_AUTHN_LEVEL_NONE,
> > RPC_C_IMP_LEVEL_ANONYMOUS, NULL, EOAC_NONE, NULL);
>
> Does anything change if you leave out CoInitializeSecurity?
No.
prose - 20 Jun 2007 22:12 GMT
Now it's getting stranger. I noticed that the one of the later changes
was adding a reference to the COM Server, so I removed it, commented
out the lines of code that needed it, and recompiled. Now it works! So
I though it must have something to do with the reference not being
found, even though I can see that it is in the same folder as the COM
Server.
I restored the original code and recompiled and dropped the object in,
but this time IT WORKS. I wonder if the DLL that was referenced was
left in memory or something. I now can't get it to fail on my
computer.
Or I wonder if I had to compile it twice for some strange reason.