Setting up a private path for loading plugin modules

Question

I am working on an application that downloads plugins. Plug-ins are in the directory below my main application directory.

It looks like:

  Myappppolder
 -----------> ThePluginFolder
 ---------------- Assembly1
 ---------------- Dependency1

My problem is with Dependency1 (this is an assembly that references assembly 1). CLR does not find it.

I read Fusion, and it looks like I can fix this by setting Private Path with currentAppDomain.AppendPrivatePath.

However, in .NET 4.0 help, they say that this method is deprecated. They point me to AppDomainSetup, but I cannot use this to change my current application domain.
Does anyone know what else I can do to download these dependencies?

Parameters that I reviewed:

• I could manually iterate over the references to Assembly1, and if I find the assembly in the plug-in folder, I can manually load it. (seems like my best option, but I want to make sure that I haven't missed anything)

• I can hook on the AssemblyResolve event of my current domain (but it even looks strange - you return a value. Does this mean that it is not a multicast? I process one aspect of the plug-in (business rule), that if another part of my application needs report plugins ? Do I need 1 global event handler?

Answer 1

Thanks for the help guys. In my case, I found that it is best to find plugins in my main application folder. Although I could load Load () or LoadFrom () to load assemblies in separate directories (and this would seem to work), I later ran into serialization problems (the assembly mentioned had classes that needed to be serialized and deserialized).

I tried using LoadFrom () and Load () by providing various data in the AssmblyName parameter. I even manually downloaded assemblies referenced by my plugins. No dynamic load will cause deserialization (I got exceptions).

I found only 3 ways to work with dynamically loaded plugins with serialization:

• Use CurrentDomain.AppendPrivatePath to add the path to the directory with my assemblies (this method is deprecated)

• Capture the ResolveAssembly event in the current AppDomain (this would work, but it was called alot, and I do not want to affect the performance of my application - note that I did not take any measurements).

• Just put the assemblies in my main directory. (This was the simplest solution, and the only argument against this was that the directory structure was not as neat as my other settings. So, everything has been examined. I took this route.

Answer 2

Plug-in assemblies are usually loaded via reflection using Assembly.LoadFrom and should not refer to your project, otherwise they are hard-coded. The only common thing between the application and the plugin is a separate assembly containing the interfaces that are referenced. Then you may have a configuration file in which you specify plugins to load at runtime.

Answer 3

This script works for me, my plugin is directly completely divided into my application directory (its web application), and dynamically loaded DLLs find links to DLL files in the same folder. Their DLL links are also loaded as plugins by my application, so he knows about their existence ...