can't cast ABC to ABC (same class???)

  • Thread starter Thread starter Ron M. Newman
  • Start date Start date
R

Ron M. Newman

Hi,

Under what circumstances can I ever get an exception about not being able to
cast type "ABC" to type "ABC" if there's only one ABC class in the system
and it's loaded from a dynamic assembly?

Thanks
Ron
 
I have seen this type of behaviour.

For us it occurred under the following circumstances :
When deployed some dll's are not stored in the same directory as the exe.
(We used the config options to set the exe to look in subdirectories for
dll's)
The same dll exists in 2 different folders.

Check to see if your app can find more than one copy of the same dll. Of
course, if all your dlls are in the same folder as your dll what I've said
doesn't apply.

HTH,

Adam.
========
 
Ron said:
Under what circumstances can I ever get an exception about not being able to
cast type "ABC" to type "ABC" if there's only one ABC class in the system
and it's loaded from a dynamic assembly?
Click to expand...

You don't have the ABC class code duplicated anywhere do you? That
would cause it.
 
if all your dlls are in the same folder as your dll
I meant "if all your dlls are in the same folder as your app exe"
 
Hi,

Under what circumstances can I ever get an exception about not being able to
cast type "ABC" to type "ABC" if there's only one ABC class in the system
and it's loaded from a dynamic assembly?

Thanks
Ron
Click to expand...

If ABC is only in a dynamically loaded class then how are you casting to
it? There can't be a cast unless there is a reference to it, as casting is
a compile time concept, not runtime.
The only cast you can do is to have a third shared DLL with a common
interface 'X', and implement it in your external class, then you can cast
to type 'X' in your main application.
Now assuming you have something like this, which as your code is compiling
I assume you have, then you must make sure the signature used by both main
and external DLLs is the same, and the best way to do this is to put your
interfaces in a separate project and reference it from both other DLLs.

Cheers,
Gadget
 
If ABC is only in a dynamically loaded class then how are you casting to
it?
Click to expand...

The main exe uses a base class, say Base.
Dll1 (no references for this in the main exe build) extends Base to Derived.
Dll2 and Dll3 create \ use Derived and both support an interface known by
the main exe.

The main exe loads up the dlls at run time and, through the interface, calls
Base GiveMeADoodah() in Dll1.
It then calls UseMyDoodah(Base o) in Dll2.

The first thing in Dll2 is :
public UseMyDoodah(Base o)
{
Derived d = (Derived) o;
...
}

And I would guess that line is where his problem his. The solution for us
was to ensure all dlls existed only in one place. When we had this issue
Dll2 and Dll3 were in 2 different sub-dirs (which was fine), but Dll1 had
somehow been deployed into both sub-directories (not fine.) It seemed as
though creation of the object involved using the dll from one sub-directory,
usage of the object involved the dll in a different sub-directory. Even
though it was the same dll you couldn't use an object created by one in the
other. (It helps if you cross your eyes and stand on your head when reading
this.)

Adam.
 
I think I get what you mean :)
I suspect .NET's 'official' solution to this is to ensure your DLL defining
'Base' is registered in the GAC.

Cheers,
Gadget
 
Back
Top