1

I gonna make a desktop application which can be added/removed modules by adding/removing dlls (each module handled by a dll) or via configuration file.

My goal is having a application like eclipse ide, there will be some basic functions (eclipse basic) as the beginning, then other functions might be installed as plugins to be a fully functionality application.

Spending some searching and end up with Managed Extensibility Framework (MEF). The problem is that MEF seems suspended to support for a long time and not many applications use it. Could anyone tell me why and should I go on with it? I have many experiences in WinForm, but WPF.

If there are any other approaches, please let me know as well.

Tu Tran
  • 1,957
  • 1
  • 27
  • 50
  • 1
    I'm afraid this is both too broad and also asking for tools. Both are not allowed here. – TaW Apr 09 '19 at 09:25
  • 1
    I have been searching for a similar plug-in based architecture, do have a look at MAF: https://learn.microsoft.com/en-us/dotnet/framework/wpf/app-development/wpf-add-ins-overview – peeyush singh Apr 09 '19 at 09:25
  • This also has not been in development for sometime , but it is available and fairly striaghtforward to use. Do be careful, it does not protect you from plugin crashing your host. You can workaround that though by launching each plugin in its own process. There are some useful link in SO for similar things, have a look at this: https://msdn.microsoft.com/en-us/magazine/dn519924.aspx – peeyush singh Apr 09 '19 at 09:27
  • Finally a SO link which can provide more insight (and more links) https://stackoverflow.com/questions/835182/choosing-between-mef-and-maf-system-addin – peeyush singh Apr 09 '19 at 09:28

4 Answers4

4

In case you want to avoid dependency on any of the extensibility frameworks such as MEF or Prism, you can also use bare reflection with assembly loading. Here is how it would work:

  • Put all the interfaces that the developers would need to implement in a separate class library and make it publicly available.
  • Extension/plug-in developers will reference that class library and will implement the interfaces in their class libraries (which will be the installable plug-ins later on).
  • Your application will allow installing/uninstalling the plug-ins (class libraries implementing the necessary interfaces).
  • Your application will discover the interface implementer classes in the plug-in libraries and will use them where appropriate.

You can learn about this approach in the following documentation pages:

It may seem a lot to learn, but it's quite straightforward after a while.

Tengiz
  • 8,011
  • 30
  • 39
3

MEF is actually a good way for such an application architecture. Saying "not so many applications use MEF" is not quite correct, because the (probably) largest and mostly known application using MEF is Visual Studio itself (starting with version 12.0 - 2013).

Now, there is some misunderstanding about MEF. There are 3 (well, three-and-a-half) versions (flavors) of MEF available. This often confuses people.

Let me try to explain:

  • MEF 1.0, also known as .NET Framework MEF. Initially released with .NET Framework 4.0; namespace System.ComponentModel.Composition.
    • pros: a part of the .NET Framework; very flexible and dynamic
    • cons: (relatively) slow; no further development
  • MEF 2.0, also known as NuGet MEF. Microsoft wanted a much faster version for Windows Phone apps and didn't need that fully dynamic approach. First released for mobile platforms only, then made available for other frameworks. It can be obtained via NuGet or using .NET Core FX. Namespace System.Composition.
    • pros: fast; now a part of .NET Core FX
    • cons: relatively "static"; poor startup performance
  • MEF 1.0+, sometimes wrongly referred to as MEF 2.0. This was the MEF 1.0 update released with .NET Framework 4.5. Pros and cons see MEF 1.0.
  • VS-MEF, a special MEF flavor that is used in Visual Studio. Can be obtained via NuGet; also see GitHub. Namespace Microsoft.VisualStudio.Composition.
    • pros: combines good performance of MEF 2.0 with almost the same flexibility as MEF 1.0; is under active development
    • cons: has no dynamic recomposition

These MEF versions have of course some differences, but any of those versions can be used for a dynamic plugin-based application. Depending on your needs, you can choose one of them. Nowadays, I would recommend either MEF 2.0 (NuGet MEF) or VS-MEF. I have a practical experience with VS-MEF and am totally satisfied with its feature set and performance.

However, MEF is not the only way. There is always an option for creating a home-grown platform for plugin-based applications. In fact, many companies go this way.

Another possibility (if you have an IoC based architecture) is to use some IoC container available (like Unity) and manually extend its functionality when needed.

dymanoid
  • 14,771
  • 4
  • 36
  • 64
2

First, MEF is a part of .NET Framework and available in .NET Core. MEF is alive and is used in a lot of projects. Last changes were a month ago for prerelease https://www.nuget.org/packages/System.Composition/1.3.0-preview3.19128.7 and of course in github (see System.Composition.*).

Second, I agreed with @mm8. Prism is a good choice. But you may see Win Application Framework (WAF).

As written in description, WAF supports:

  • WPF (Windows Presentation Foundation)
  • UWP (Universal Windows Platform)
  • Core (Basic support for all .NET based applications)

See Modular Architecture section for more details about configuring of modularity. WAF uses MEF under the hood. See a good example for configuring https://github.com/jbe2277/waf/blob/master/src/System.Waf/Samples/InformationManager/Assembler/App.xaml.cs

Part of the code using MEF and WAF from the example:

// An aggregate catalog that combines multiple catalogs
var catalog = new AggregateCatalog();
// Add the WinApplicationFramework assembly to the catalog
catalog.Catalogs.Add(new AssemblyCatalog(typeof(ICustomService).Assembly));

// Load module assemblies from files *.Presentation.dll and *.Applications.dll
foreach (string moduleAssembly in GetCustomModuleAssemblies())
{
    catalog.Catalogs.Add(new AssemblyCatalog(moduleAssembly));
}

var container = new CompositionContainer(catalog, CompositionOptions.DisableSilentRejection);
var batch = new CompositionBatch();
batch.AddExportedValue(container);
container.Compose(batch);

// Initialize all presentation services
var presentationServices = container.GetExportedValues<IPresentationService>();
foreach (var presentationService in presentationServices) { presentationService.Initialize(); }

// Initialize and run all module controllers
moduleControllers = container.GetExportedValues<IModuleController>();
foreach (var moduleController in moduleControllers) { moduleController.Initialize(); }
foreach (var moduleController in moduleControllers) { moduleController.Run(); }

Third, I advise using WPF or Avalonia (cross-platform .NET UI framework) for desktop UI instead of WinForms.

Didgeridoo
  • 1,222
  • 2
  • 14
  • 21
1

You should take a look at Prism. It's an open-source framework for building loosely coupled, maintainable, and testable XAML applications in WPF, Windows 10 UWP, and Xamarin Forms.

It supports adding modules using configuration as seen in this example: https://github.com/PrismLibrary/Prism-Samples-Wpf/tree/master/07-Modules%20-%20AppConfig

mm8
  • 163,881
  • 10
  • 57
  • 88