5

We are building a .NET application where we load external code assemblies ("plugins"). Up to this point, we were loading these assemblies into a single (main) application domain.

We would like to be able to unload an assembly after it has been loaded.

To this end, we are designing a system that will create a separate secondary AppDomain to host the plugin assemblies, to be unloaded at will.

The problems we have with this approach:

  1. The plugin DLL will need to interact with classes in the main AppDomain (logger, for example).
  2. The data that is sent to the plugin dll is not necessarily marked as Serializable or derived from MarshalByRefObj.

Is there any common practice of partitioning the application in such cases? What is the best solution we could go for ?

Another interesting question -- why doesn't MarshalByRef goes by an attribute and forces us to derive from an object?

lysergic-acid
  • 19,570
  • 21
  • 109
  • 218
  • 1
    `We would like to be able to unload an assembly after it has been loaded` http://stackoverflow.com/questions/6258160/unloading-the-assembly-loaded-with-assembly-loadfrom 1. To interact across separate AppDomains you'll probably need to do it via Remoting. 2. is a statement, could you edit to clarify that 2nd question – Jeremy Thompson Jan 19 '12 at 00:36

1 Answers1

3

The simplest way to communicate across AppDomains is to use AppDomain.CreateInstanceAndUnwrap . This will allow you to instantiate an object in another AppDomain and return a proxy to that object. From the proxy you can effectively make method calls across the app domain.

If your current classes do not extend MarshalByRef then you should create a bridge class that does and can act as a go-between.

Samuel Neff
  • 73,278
  • 17
  • 138
  • 182