-1

I'm developing an application with .NET and this application must be able to load different plug-in (dll). The application is a simple Form that show the selected plug-in and the plug-in are UserControl with inside all the necessary control for implement the features.

I'm thinking to develop both, application and plug-in, with c# but the first with .NET Framework standard and the seconds with WPF (and use ElementHost control in the application to visualize the plug-in in WPF).

First question: in this way, when I load the plug-in, the different assembly should be compatible, right?

I have tried to develop this system in three ways:

  1. using the class Assembly and loading manually the plug-in.
  2. using the MEF
  3. using the MAF

Second question: in the life of system, could happen that some plug-in are made with a old WPF version and other with last WPF version. Which the best solution among those listed above to guarantee that, if for example I load a plug-in with an older version of WPF after loading a plug-in with a newer version of WPF, the application use the correct version of WPF (older version in the example)?

Furthermore I need to implement a system to install and unistall plug-in in runtime. With 3) I was able to implement it. With 1) and 2) I read on-line that the only way to unistall plug-in in runtime, it's to load the assembly plug-in in a secondary AppDomain (with class Assembly or with MEF), make serializable the classes of plug-in and unload the AppDomain when necessary: Unload a dll file in mef

With this strategy however, I encountered a problem: when I use the insance of assembly loaded in secondary AppDomain (I have to insert this instance in the main Form), the main AppDomain serializes the instance and recreates it but in doing so, in addition to losing the benefits of the MEF, the assembly remains locked on the main AppDomain and I can not uninstall the plug-in. To avoid it I have to set ShadowCopyFiles = "true" in main and secondary AppDomain but I can have the same problem updating a plug-in in which there will be an updated dll but with the same name (the shadow copy will still be blocked).

Third question: is there a different solution for implement it with 1) or 2)?

LucaG
  • 74
  • 9

1 Answers1

0

Regarding 3th question, just yesterday with one of the last tests I did (found on various forums), maybe I could find a way to load the assemblies to the MEF without blocking the files, without using another AppDomain (which anyway is a cumbersome operation) and therefore without using ShadowCopy: the idea is to read the dll and put the contents on a byte array, create an AssemblyCatalog from this Array and then add the created AssemblyCatalog to the catalog of the MEF:

CompositionContainer _container = null;
.
.
.
AggregateCatalog catalog = new AggregateCatalog();
.
.
.
String fileName = "pug-in1.dll"
.
.
.
Byte[] contFile = File.ReadAllBytes(fileName);
Assembly ass = Assembly.Load(contFile);
AssemblyCatalog assCat = new AssemblyCatalog(ass);

catalog.Catalogs.Add(assCat);

_container = new CompositionContainer(catalog)

try
{
    _container.ComposeParts(this);
}
catch (CompositionException compositionException)
{
    Console.WriteLine(compositionException.ToString());
}
.
.
.

It seems to work and the files are not blocked

LucaG
  • 74
  • 9