Loading assembly in a seperate process

Hi,

It is trivial to load an assembly in a new Application Domain. Is there
any way of loading an assembly in a new process?

I tried using the Process class like this:

Process p = new Process()
p.StartInfo.FileName = mStartupFile
p.StartInfo.UseShellExecute = False
p.StartInfo.WindowStyle = ProcessWindowStyle.Hidden
p.StartInfo.RedirectStandardOutput = True
p.Start()
string text = p.StandardOutput.ReadToEnd()
p.WaitForExit()

Though this works for exes, it doesn't for DLL assemblies. On my system
Dll is associated with Dependency Walker so it just opens the assembly
up in it.

How would I go about doing a LoadAssembly in a seperate process?

Thanks...

Ali

re: Loading assembly in a seperate process

> How would I go about doing a LoadAssembly in a seperate process?

You could write a simple EXE that does nothing more than load the DLL you
want and invoke a method in it.


Mattias

re: Loading assembly in a seperate process

<ali.jan@gmail.com> wrote in message
news:1135067426.816208.206450@g49g2000cwa.googlegr oups.com...[color=blue]
> Hi,
>
> It is trivial to load an assembly in a new Application Domain. Is there
> any way of loading an assembly in a new process?
>
> I tried using the Process class like this:
>
> Process p = new Process()
> p.StartInfo.FileName = mStartupFile
> p.StartInfo.UseShellExecute = False
> p.StartInfo.WindowStyle = ProcessWindowStyle.Hidden
> p.StartInfo.RedirectStandardOutput = True
> p.Start()
> string text = p.StandardOutput.ReadToEnd()
> p.WaitForExit()
>
> Though this works for exes, it doesn't for DLL assemblies. On my system
> Dll is associated with Dependency Walker so it just opens the assembly
> up in it.
>
> How would I go about doing a LoadAssembly in a seperate process?
>
> Thanks...
>
> Ali
>[/color]

You can only load assemblies in your own process, not in a spawned process.
So it's up to the spawned process to load the assembly.
What exactly do you wan't to achieve, as I see no use for such remote
assembly loading?

Willy.

re: Loading assembly in a seperate process

Hi,

I have got a variety of code written in a .net assembly. There is a
workflow engine in C++ that depends a lot on this code. The guys
working on the engine are worried about issues like .NET framework
memory leaks. For example we have been burned once by the XmlSerializer
leak.

So, the engine guys want a mechanism by which they could unload the
assembly and get rid of the .NET memory leaks and then reload it.
Another restriction we have is that the .net assembly has to be loaded
in-process with the engine.

I tried doing this with an Appdomain. I created a new Appdomain and
loaded my assembly in the engine using a proxy etc. Now the assembly
does get unloaded and the Appdomain destroyed but the memory leaked
remains.

So, now I was thinking of loading my assembly out of process... but
that's not allowed either due to several other problems in interaction
with the engine.

It is important to note that we are NOT worried about our own memory
leaks that we could control one way or the other but we are worried
about the leaks in the framework. Is there any solution to this problem
other than dumping .net?

Thanks...

Ali

re: Loading assembly in a seperate process

<ali.jan@gmail.com> wrote in message
news:1135158716.570924.276360@g47g2000cwa.googlegr oups.com...[color=blue]
> Hi,
>
> I have got a variety of code written in a .net assembly. There is a
> workflow engine in C++ that depends a lot on this code. The guys
> working on the engine are worried about issues like .NET framework
> memory leaks. For example we have been burned once by the XmlSerializer
> leak.
>[/color]
How did you solve it?
[color=blue]
> So, the engine guys want a mechanism by which they could unload the
> assembly and get rid of the .NET memory leaks and then reload it.
> Another restriction we have is that the .net assembly has to be loaded
> in-process with the engine.
>
> I tried doing this with an Appdomain. I created a new Appdomain and
> loaded my assembly in the engine using a proxy etc. Now the assembly
> does get unloaded and the Appdomain destroyed but the memory leaked
> remains.
>[/color]

What leak? Did you identified the leak?
[color=blue]
> So, now I was thinking of loading my assembly out of process... but
> that's not allowed either due to several other problems in interaction
> with the engine.
>
> It is important to note that we are NOT worried about our own memory
> leaks that we could control one way or the other but we are worried
> about the leaks in the framework. Is there any solution to this problem
> other than dumping .net?
>[/color]

Please explain how you can control your own leaks? And what leaks you are
talking about (what kind of memory? Did you run a profiler/debugger to
correctly identify the kindk of leak?.


Willy.