Loading assembly in a seperate process

[ali.jan]

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.Fil eName = mStartupFile
p.StartInfo.Use ShellExecute = False
p.StartInfo.Win dowStyle = ProcessWindowSt yle.Hidden
p.StartInfo.Red irectStandardOu tput = True
p.Start()
string text = p.StandardOutpu t.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

[Mattias Sjögren]

> 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

[Willy Denoyette [MVP]]

<al*****@gmail. com> wrote in message
news:11******** **************@ g49g2000cwa.goo glegroups.com.. .

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.Fil eName = mStartupFile
p.StartInfo.Use ShellExecute = False
p.StartInfo.Win dowStyle = ProcessWindowSt yle.Hidden
p.StartInfo.Red irectStandardOu tput = True
p.Start()
string text = p.StandardOutpu t.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

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.

[ali.jan]

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

[Willy Denoyette [MVP]]

<al*****@gmail. com> wrote in message
news:11******** **************@ g47g2000cwa.goo glegroups.com.. .

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.
How did you solve it?
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.

What leak? Did you identified the leak?
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?

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.