Loading assembly in a seperate process

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • ali.jan@gmail.com

    #1

    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.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

    #2
    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

    Comment

    • Willy Denoyette [MVP]

      #3
      Re: Loading assembly in a seperate process


      <ali.jan@gmail. com> wrote in message
      news:1135067426 .816208.206450@ g49g2000cwa.goo glegroups.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.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
      >[/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.


      Comment

      • ali.jan@gmail.com

        #4
        Re: Framework Memory Leaks Was 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

        Comment

        • Willy Denoyette [MVP]

          #5
          Re: Framework Memory Leaks Was Loading assembly in a seperate process


          <ali.jan@gmail. com> wrote in message
          news:1135158716 .570924.276360@ g47g2000cwa.goo glegroups.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.


          Comment

          Working...