CoCreateInstance fails with "Class Not Registered" when in fact, i

[SteveL]

I was told to move my question to this forum:
---------------------------------------------
I have a C# class which is being called via COM interop from a legacy c++
program compiled under VC7 (VS2003). It worked well before we converted our
C# codebase to VS2005 (.NET 2.0) and now we have the "Class not registered"
result from CoCreateInstance in our C++ code.

The thing is, I can see the GUID in the HKEY_CLASSES_ROOT registry. We
noticed that a new version of RegAsm was supplied with VS2005 (we're up to
date with SP1), and even when we manually register the class library with
RegAsm, (which succeeds) the C++ code can't find the registry entry.

I've checked the GUID and it's identical. Anyone else having this problem?

Here's the C# code wrapper for the COM class:
#region Interface published by your COM class
[Guid("346FFA5F-840C-4728-85AA-F789900F159A"),
InterfaceType(ComInterfaceType.InterfaceIsDual) ]
public interface IOrderEdit
{
[DispId(1)] System.IntPtr RunOrderEditForm ( string dbParams, int
mode, string title, string paramsAsXml );
}
#endregion

[ Guid("DA8FA26B-D07F-40D0-ACB2-40B6665F1A11"),
ProgId("ComUI.OrderEditUI"),
ComVisible(true),
ClassInterface(ClassInterfaceType.None),
ComSourceInterfaces(typeof(IOrderEditUIEvents)) ]
public class OrderEditUI : IOrderEdit
{
// ... class contents skipped for brevity
}

Here's the C++ code that tries to load the COM objects:

IOrderEditPtr spOrdEdit = NULL;
LPOLESTR lpolestr;
StringFromCLSID(__uuidof(OrderEditUI), &lpolestr);

HRESULT hr = spOrdEdit.CreateInstance( __uuidof(OrderEditUI) );

if ( spOrdEdit )
{
// ... stuff we might do if we got this far, deleted for brevity
}

I added the StringFromCLSID to make sure I was looking for the right guid
and I'm looking for this one: DA8FA26B-D07F-40D0-ACB2-40B6665F1A11

I tried running RegMon (SysInternals) and interestingly on the second pass
through the code (first time through it fails with Class not registered as
before), I get an unknown error code in hr = -2146234105 which seems to be
undocumented.

Any help would be very much appreciated...

Check if the interface is registered for marshaling. In general, post
microsoft.public.dotnet.framework.interop

However, as I understand it from Dr. GUI, this would mean registering the
component as both a proxy and a stub, but I don't believe that is necessary
as this is not a remote interface. Note that this all worked when I was
calling a .NET 1.1 class from VC7 C++ code. It is only since I've updated to
the .NET 2.0 framework that I'm having the problem. I did unregister the
class and reregister it to avoid confusion.

Thanks for any help!

[Mattias Sjögren]

Post by SteveL
I tried running RegMon (SysInternals) and interestingly on the second pass
through the code (first time through it fails with Class not registered as
before), I get an unknown error code in hr = -2146234105 which seems to be
undocumented.

That would be 0x80131107 in hex representation, which is the error
CLDB_E_FILE_OLDVER (see Corerror.h in the .NET SDK).

Sounds like maybe the application is loading the 1.x version of the
CLR and then fails to load this assembly that was compiled for 2.0.


Mattias

[umesh]

Hi Steve,

I too had this problem but no more now.
Does strong naming is enabled on your computer ? If not or if you don't want
it then you will face this problem. Even if you see your C# class
registered in registery you will get the "Class Not Registered" error. To
make it work you need to place the the c# library in the same location where
the application using it is residing.

If you don't want to do that then you can use GAC and strong naming.

Hope this will help you.

Post by Mattias Sjögren

Post by SteveL
I tried running RegMon (SysInternals) and interestingly on the second pass
through the code (first time through it fails with Class not registered as
before), I get an unknown error code in hr = -2146234105 which seems to be
undocumented.

That would be 0x80131107 in hex representation, which is the error
CLDB_E_FILE_OLDVER (see Corerror.h in the .NET SDK).
Sounds like maybe the application is loading the 1.x version of the
CLR and then fails to load this assembly that was compiled for 2.0.
Mattias
--
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.