"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.comwrote in message
news:OL**************@TK2MSFTNGP06.phx.gbl...
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.
