Unamanged types in managed interface generates TypeLoadExcep

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: cdrundles (crundles_at_russellmellon-dot-com.no-spam.invalid)
Date: 02/02/05 

Date: 2 Feb 2005 11:58:41 -0600

I received the same error in very similar circumstances.
The failure happened when calling a delegate whose interface is
abstract and whose implementation overrides the interface method.

First thing to verify is that the override keyword is in the
implementation.
Second thing to verify is that the implementation has the same
signature
as the interface (delegate). This can be verified by running:

C:\Program Files\Microsoft Visual Studio .NET
2003\SDK\v1.1\Bin\ildasm.exe (a GUI app)

and opening the DLL containing the implementation and then the one
containing the interface.

The next thing to do is to see if the implementing assembly fails to
load:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cptools/html/cpgrfFusionLogViewerFuslogvwexe.asp
give instructions concerning the Fusion Log Viewer.
Bear in mind that this article should have said to add the DWORD
registry variables it refers to as they are not present by default.

In my case, the assembly loaded with no errors. This turned out to be
misleading, for the type load failure was caused by the inability to
load
an assembly on which the current delegate depended.

In particular, the delegate was implemented in one C++ DLL but
returned an object pointer defined in another C++ DLL. It was the
latter DLL that failed to load and yet fuslogvw showed no errors.

My error was resolved by copying the DLL, on which the delegate
implementation depended, to the current directory. I didn't try
having the DLL in LIBPATH, but that may have been sufficient. If you
see success on one system and failure on another, LIBPATH may be an
issue. Since LIBPATH differs for users and system, a load may
succeed for a user but fail for a service. Either way, having the
DLLs in the current directory works.
*---------------------------------*
Posted at: http://www.GroupSrv.com
*---------------------------------*

 Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
    ** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
                http://www.usenet.com

Relevant Pages

  • Re: Type library cannot be re-imported as a CLR assembly
    ... The only possibility is to load a dll by browsing to its location ... __declspecint CallFromAV1{ ... if the native application defined a COM interface for plugins or whatever, then the .NET application can implement that interface, and the native app can use it. ...
    (microsoft.public.dotnet.framework.interop)
  • Re: Inheriting an interface from COM obj
    ... I wouldn't jump to any immediate conclusions based on the fact that the dll ... wont load in your client application. ... works for the interface you were supposed to inherit from e.g. ...
    (microsoft.public.win32.programmer.ole)
  • Re: COM Question
    ... Use Assembly.LoadFrom(path) to load the assembly, ... the interface (or base class - it doesn't have to specifically be an ... Each new object will reference this same DLL to get the ... Your "consumer" app also references the original base that holds the ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: MULTI_QI
    ... >> So to have client be able dynamically load some COM dll, ... Imagine you are given a DLL implementing ... >> interface is to provide a way to discover what SERVER has to offer.... ... > Again, look at IDispatch. ...
    (microsoft.public.vc.atl)
  • Accessing a C# delegate used in a C# interface....
    ... to implement the project in VB.NET, so the EXE project is a VB WinForms ... Of interest in my problem are two C# DLL projects aside from the main ... Then, an interface in the ... Remember that the interface in B, uses the delegate in A, so ...
    (microsoft.public.dotnet.languages.vb)