(2nd Attempt) Passing Objects

[Bryan Martin]

I have a object that is created in a seperate domain which needs to be
passed back to the parent class. Because this object is created in a
seperate domain if I try to pass the object back to the parent class
(different domain) I receive an error about "File Not Found". I know the
object is created successfully and the objects method can be called after
loading the object however upon passing it back to the calling class it
exploades. I do not want to proxy everything though the loader class so it
can be versitile enough to load other objects with different methods. I
would much rather pass the loaded object back to the parent and have it deal
with what class/methods.

The original post from Thursday, July 31, 2003
Scenario is to load assembly in its own domain and return objects back to
the parent for later use. Plug-in style

ParentProgram
Creates a new class named PluginLoader and calls sub loadassembly

PluginLoader
LoadAssembly creates a new appdomain and new class PluginProcessor. Next it
lets pluginprocessor load the actual objects needed from the assembly
because I need this to run in its own appdomain so I can unload it if need
be.

PluginProcessor
Loads the assembly and gathers the required objects. Right after loading
object, method is called inside the object and works fine. Next I try to
return this object back to PluginLoader. PluginLoader attempts to call
method inside object and fails with "File or assembly name LoadedObject, or
one of its dependencies, was not found."

What am I missing? How do I get the object back to the parent? I know it
was found due to being able to call the methods inside PluginProcessor
successfully.

Bryan

 

[Steve S]

When you say......... DOMAIN...... do you mean... application process
space or a true domain ?

Assuming you mean... application process space...... as building a DOMAIN
on the fly could be an interesting challenge but not very practical for many
purposes....... applications must know where the objects are... and the
references that are created are just pointers to the process space..... If
your loader pulls the object up... it probably is in it's own process
space...... and not sitting out somewhere for other applications to
reference.....

While this hasn't offered alot of information on how to fix your
situation...... assuming that you do create a means to create all of the
objects .... OUT OF PROCESS.... to run in their own spaces.... (for
whatever reasons)... the jump across process boundries..... isn't real
nice... and it does cost performance.... and there are certain types of
objects that WILL NOT cross boundries.... (no matter what you do... that
is by design)

While I don't want to pry too far into your objects... or the over all
design... maybe I should ask... How are you going to UNLOAD IT ? Is this
going to run somewhere like COM+ services ? How will you kill off just ONE
instance ? Let's say you can.... which one of the 10 loaded do you kill
off ? Does it have any other processes that it points to ? what happens
to the process count of those objects ? Or do you increment the process
count... everytime you pass the reference to the object... and decrement
it accordingly ? If the components your loader creates is ActiveX style...
how do you manage the references when the loader gets created by different
applications?

I'm sure you have all the bases covered in your design..... and have built
error trapping to handle all the situations....... like what was a valid
reference in an application... just turn invalid because you destroyed the
object it was referencing.....

 

[Jon]

Normally you pass a common interface or a common abstract class between the app domains.

Do you plan to pass the whole new type back, and have the parent use reflection to access the properties?

 

[Bryan Martin]

By domain I do mean application domain. The purpose behind this is to load
the object(s) dynamically. Because I need to be able to unload the
object(s) is why I choose the seperate domain loading in the first place.
To my knowledge the only way to unload a assembly that has been loaded
dynamically is to unload the actual domain instead (which for all intense
and purposes has worked thus far). All dynamically loaded assemblies must
inherit there respected interface. By looping though all types inside the
assembly I can make sure they do infact adhear to this rule prior to
loading. You are correct in that because the object is initiated in its own
domain I cannot access the object from the parent class. This is what
prompted the question. Because everything must implement the given
interface I plan to use the parent class for marshaling everything though to
the loaded objects. And using the parent class with good error handling for
all marshalling should allow for a one stop solution to most of the
questions about dealing with certain circumstances.

Bryan

 

[Bryan Martin]

My load function looks something like this

Function Load(ByVal AssemblyName as string, ExpectedType as Type)as object

After loading the assembly I loop though the types finding all that equal
the expectedtype.

I have also passed a class of expected type to the function and set it to
the newly created object. This allows me to use the class to call the
methods successfully inside this domain but when it gets passed back I still
get bombed.

Thanks for your time.
Bryan

Normally you pass a common interface or a common abstract class between the app domains.

Do you plan to pass the whole new type back, and have the parent use

reflection to access the properties?

 

[Jon]

Seach MSDN for "AppDomains and Dynamic Loading" C# sample.
I think it is very similar to what you are trying to accomplish.

 

[Bryan Martin]

Ohhhhh I owe you big time. This was exactly what the problem was. After
correcting this it works like a charm.

Solution was:
The class that was being loaded did not inherit MarshalByRefObject. Where
in the heck were you a week ago when this problem began?

Again I cant thank you enough Michell. *blushing*