Registration problem with COM interop sample.

[Guest]

Hi,

I'm using the the MSDN sample "COM Interop Part 2 Sample"
(CSharpServerWithCOMClient.sln). The C# COM component gets registered when
the solution is built. Somehow the component doesn't get registered properly.
When opened with OLE/COM Viewer the component throws up an error saying:

"CoGetClassObject failed.
The system cannot find the file specified.
severity: SEVERITY_ERROR, facility: FACILITY_WIN32($80070002)"

Not sure what is going wrong. Appreciate any help. Is there anything
specific that needs to be done?

TIA,
SD

 

[Nicholas Paldino [.NET/C# MVP]]

SD,

Nothing is going wrong. The assembly produced by .NET is still a .NET
assembly. If you look at the registry entries for your component that is
registered for COM interop, you will see that the InProcServer32 value
doesn't point to your component, but rather points to a framework component.
This is because COM interop is handled through the CLR, and not baked into
your .NET component.

That's why OLEView fails. It's trying to read a .NET component as a COM
component, when that isn't the case.

Hope this helps.

 

[Willy Denoyette [MVP]]

Hi,

I'm using the the MSDN sample "COM Interop Part 2 Sample"
(CSharpServerWithCOMClient.sln). The C# COM component gets registered when
the solution is built. Somehow the component doesn't get registered properly.
When opened with OLE/COM Viewer the component throws up an error saying:

"CoGetClassObject failed.
The system cannot find the file specified.
severity: SEVERITY_ERROR, facility: FACILITY_WIN32($80070002)"

Not sure what is going wrong. Appreciate any help. Is there anything
specific that needs to be done?

TIA,
SD

This: 80070002 means "File not found", so the Client (COM) is not able to locate the server
DLL.
To resolve you have several options:
- install the client in the same location as the DLL, or
- register the DLL using " regasm.exe" with the /codebase switch from the command line, or
- install the DLL in the GAC, using gacutil.exe.

Willy.

 

[Willy Denoyette [MVP]]

SD,

Nothing is going wrong. The assembly produced by .NET is still a .NET assembly. If
you look at the registry entries for your component that is registered for COM interop,
you will see that the InProcServer32 value doesn't point to your component, but rather
points to a framework component. This is because COM interop is handled through the CLR,
and not baked into your .NET component.

That's why OLEView fails. It's trying to read a .NET component as a COM component,
when that isn't the case.

Hope this helps.

This is not true, if you *register a .NET assembly as a COM component either from VS or by
using regasm, you are registering mscoree.dll as the COM server and your assembly and
class(es) as a COM class(es) (both as InProcServers).
mscoree is the shim that loads the CLR, so when you start OLEVIEW, mscoree will load and
this one will automatically load the CLR as a result of a call into COM (the creation of an
instance of your .NET class).
If however, your assembly is not in the clienst path, mscoree.dll will not be able to locate
your assembly and this will produce the HRESULT as mentioned by the OP. One way to solve
this is by applying the codebase switch to regasm or installing the assembly in the GAC.

Willy.