AppDomain.CurrentDomain.AppendPrivatePath("myPath"); alternatives?

I'm dynamically loading .dlls, and I'd want to load them from a subdirectory of where my .exe is located.

To get something like Assembly.Load("SomeAssembly"); where SomeAssembly.dll is located under "DLLs\" ,I've done

 AppDomain.CurrentDomain.AppendPrivatePath("DLLs"); 

This works fine, but apparently AppendPrivatePath is deprecated. I'm t开发者_运维百科old what replaces it is to place this in my app.config

 <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <probing privatePath="DLLs"/>
    </assemblyBinding>
  </runtime> 

However, this has no effect. Assembly.Load("SomeAssembly") throws an exception that SomeAssembly could not be found. So how do I get this working ?

I could ofcourse:

• Continue to use AppDomain.CurrentDomain.AppendPrivatePath("DLLs"); , even though it's deprecated.
• Place all my plugin .dlls in the same directory as the .exe (meh...)

---

you can use manual assembly resolution to do this.

You need to provide a delegate to the AssemblyResolve event in the current AppDomain

AppDomain currentDomain = AppDomain.CurrentDomain;
currentDomain.AssemblyResolve += assemblyResolver.ResolveEventHandler;

when the application has any assembly references that it can't resolve it will call this delegate to get the assembly resolved. You can then simply return the assembly requested from the delegate:

Assembly assembly = Assembly.LoadFrom (assemblyPath);
return assembly;

hope this helps

---

No, the <probing> element is known to work well. You may find this doesn't have an effect when you run the code in the debugger. That's because of the "Visual Studio Hosting process", a customized version of the CLR that improves debugging.

Copy yourapp.exe.config to yourapp.vshost.exe.config. Or disable the hosting process: Project + Properties, Debugging tab.