如何在Visual Studio中组织模块化（C＃/ MEF）应用程序以允许调试？

Question

I am in the process of developing a modular application using C# and MEF. The application is supposed to consist of

• a main application , which is the actual executable, providing core functionality, exposing a number of interfaces (extension points) and using MEF to pull in plug-in assemblies that fit into these
• a set of plug-ins that provide classes that fit into the interfaces and can be used by the main application

The main application may either run all by itself or with one or more plug-ins imported. This should be a rather standard architecture for a modular MEF-based application. Initial tests have shown that this appears to generally work. If I deploy the main application as well as one or multiple plug-in assemblies in to a folder, everything works fine.

However, I am struggling with how to organize the Visual Studio solution for this. My initial approach is that the main application, as well as each plug-in are separate projects within a solution. The main application is an exe project, whereas the plug-ins are dll projects. Plug-in projects depend on the main project, since they are implementing interfaces and using classes defined in the main application (I could have created a common lib project that does this, but it does not seem to add any benefit).

This way, I can start and debug the main application (with no plug-ins) fine.

But how can the solution be organized so I can debug the main application with one, multiple or all plug-ins? The current approach builds each plug-in into its own folder (which is generally fine) and copies the main application into each of these (which is not quite desirable). I could potentially configure an individual plug-in project to start the main application in its output folder, but I have no idea how to do this for more than one plug-in or how to do this if the main application should not be copied into each plug-in output folder.

Any hints or best practices would be highly appreciated. I am using Visual Studio 2015 - if that makes any difference.

Answer 1

Plug-in projects depend on the main project, since they are implementing interfaces and using classes defined in the main application (I could have created a common lib project that does this, but it does not seem to add any benefit).

There are benefits to it, here's a couple of them:

• it just makes sense that if you have multiple projects which are all using the same classes/functions, that these reside in a seperate common project. And possibly even another seperate project just for the interfaces. It makes it easier to grasp things, seeing a solution where you have a main application, some dlls with common functionality, some plugins
• suppose you once have to add another main app then that can just make use of the common dll as well, instead of having to reference the first main app
• you won't end up with your main app being copied x times to other project's output directories because they depend on it
• it seems a bit strange (to me at last) that other projects have an exe project as dependency, rather than a dll project. Just like it is really weird to me that a plugin depends on the main application it is in turn loaded in. Might be just me though - but I think it's also one of the reasons you have to ask the rest of your question in the first place.

But how can the solution be organized so I can debug the main application with one, multiple or all plug-ins?

Typcially you tell your main application at startup which plugins to load. There are different ways to do this: read a file containing names of plugins, scan a known directory for plugins, a combination. All supported or relatively easy to implement using MEF. For instance for one large C# app we have, all plugins are copied into something like bin\\Plugins. When the application starts it looks for dlls in bin\\Plugins, filters the list based on a textfile containing regexes, then loads plugins from the filtered list. When sending the application to customers they get all, or only some plugins. When developping we use the text file to cut down application load time.