AppDomain.Load() is only meant to be called on AppDomain.CurrentDomain. (It’s meant for interop callers only. They need a non-static method, and Assembly.Load() is static.) If you call it on a different AppDomain, if the assembly successfully loads in the target appdomain, remoting will then try to load it in the calling appdomain, potentially causing a FileNotFoundException/SerializationException for you.

If you need to execute an exe, use AppDomain.ExecuteAssembly() or (starting in v2.0) AppDomain.ExecuteAssemblyByName() instead. Otherwise, you should change to use Assembly.Load() from within the target appdomain. See Executing Code in Another AppDomain for more info.

Comments (8)

  1. Kabbe says:

    Hi Suzanne!
    I’m a little lost when it comes to calling components in another exe.
    In COM it was so easy doing this, that we built all our system in this way ,small 3-tierd applications that worked together where the GUI-component could use other GUI-components. Example: to choose a customer for a Contract, the Contract.exe would call CustomerManager.SelectUser(), which would be in the Customer.exe and would show the ListCustomers dialog.
    How do I do this in .NET?
    From what I have read it seams like AppDomain is the way to go. Sure, you could use some remoting mechanism but I can’t see the point of this since it all happens on the same machine and remoting is mainly used for communicating with remote components.

    I would be thankfull for anything that can nudge me in the right direction.

  2. Suzanne says:

    You could still use remoting for process-to-process communication. (Actually, when you transfer objects from one AppDomain to another in the same process, it automatically uses remoting.)

  3. TheCPUWizard says:

    I have to disagree with Kabbe on this one. If you are communicating between processes especially on different machines (or if there is the potential for different machines in the future because of load leveling, etc) I believe that an SOA is thw way to go. Given current technologies, this means WCF.

    My company has limited remoting to ONLY RPC within a single process for the last 2+ years. Overall it has been a very good and solid move for our product line(s).

  4. Ibrar says:

    AppDomain.load IS AN INSTANCE METHOD !!!!

    "They need a non-static method, and Assembly.Load() is static."

    The first part is right, it is non-static then you contradict yourself by saying that the method in question is static.

  5. Ibrar:

    I think there is a misunderstanding here. There is a Load() method in the Assembly class as well as the AppDomain class. The Assembly one is static; the AppDomain one is not. The point of the quoted sentence was to point out why AppDomain.Load() exists considering there is Assembly.Load().

  6. Keith Patrick says:

    Just as an FYI for those who may miss minute details (like myself): that MarshalByRefObject subclassing is crucial. I had been trying this without it, but I had loaded an assembly containing the launcher class in both appDomains. However, loading the assembly still resulted in both domains loading the assembly (and an error in the parent domain). Once the call is being done via marshaling, the problem went away, and everything worked exactly as expected.

  7. Igor Skomorokh says:

    Is it possible to load an assembly in separate AppDomain and return the reference on an assembly object to the main AppDomain?