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.....
"Bryan Martin" <sp**@ahwayside.com> wrote in message news:us5eCoiWDHA.652@TK
2MSFTNGP10.phx.gbl...
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