none
Assembly.LoadAssembly, MEF and MAF: how are the different assemblies of the Framework managed and how to implement a system for uninstalling plug-ins? RRS feed

  • Question

  • 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?

    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.

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

    Forth question: Is the MAF technology already considered obsolete and will it be replaced soon?

    Thank you in advance.

    Luca G.

    Thursday, August 2, 2018 7:27 AM

All replies