Welcome to MSDN Blogs Sign in | Join | Help

AppDomain.Load()

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.

Published Monday, June 16, 2003 1:37 PM by Suzanne Cook
Filed under:

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

# RE: AppDomain.Load()

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.
Thursday, June 19, 2003 6:44 AM by Kabbe

# RE: AppDomain.Load()

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.)
Friday, June 20, 2003 6:02 PM by Suzanne

# re: AppDomain and Shadow Copy

Friday, July 02, 2004 8:41 PM by Junfeng Zhang's .Net Framework Notes

# re: AppDomain.Load()

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

Friday, September 14, 2007 7:38 AM by TheCPUWizard

# Suzanne Cook s NET CLR Notes AppDomain Load | Cast Iron Cookware

PingBack from http://castironbakeware.info/story.php?title=suzanne-cook-s-net-clr-notes-appdomain-load

Thursday, June 11, 2009 10:32 PM by Suzanne Cook s NET CLR Notes AppDomain Load | Cast Iron Cookware

Leave a Comment

(required) 
required 
(required) 

  
Enter Code Here: Required
 
Page view tracker