0

Imagine that I have decoupled my code beautifully:

  • Library Contracts to one assembly
  • Library Implementation to another assembly
  • App code depends on the Library Contracts only
  • MEF takes care of loading the right implementation at run-time

The only problem is - how do I get the Library Implementation assembly into the bin folder of the App, now that App does not depend on it?

(In fact, no code, except unit tests depend on Library Implementation, after all this is a perfect decoupling)

I know of two approaches:

  1. Make App depend on the Library Implementation project anyway.
  2. Some msbuild targets focus pocus to copy Library Implementation assembly into the App bin directory

But both feel as wrong. Is there a better way to achieve this goal?

mark
  • 59,016
  • 79
  • 296
  • 580
  • Copy to output directory, like you would do with a asset folder, configration defaults file and similar stuff? – Christopher Dec 03 '19 at 00:47
  • The idea of MEF is to create a plug in system, where you do not deliver that library at build time, really. You can load it in resources, have users add it themselves, build a plugin loading system, load it from nuget or wherever, really. – zaitsman Dec 03 '19 at 00:50
  • 1
    In places I've worked that used MEF, each assembly was built independently, but at deployment time, all of the loadable assemblies were deployed to a common folder. In practice, we used post-build events (rather than "Copy always" directives). Doing it that way allows developers to build everything and end up with a runnable system on their local machines. However, you could decouple if further if you want (but your maintenance devs will likely curse you later) – Flydog57 Dec 03 '19 at 00:58
  • @zaitsman not really, MEF isn't a plug-in system. Perhaps you are thinking of _[MAF](https://learn.microsoft.com/en-us/previous-versions/dotnet/netframework-4.0/bb384200(v=vs.100))_? MEF is just a _zero-configuration DI system unlike a true plug-in framework like MAF. _[Choosing between MEF and MAF (System.AddIn)](https://stackoverflow.com/questions/835182/choosing-between-mef-and-maf-system-addin)_ –  Dec 03 '19 at 01:29
  • Nope. https://learn.microsoft.com/en-us/dotnet/framework/mef/ is IoC that allows you to build plugins. kind of. – zaitsman Dec 03 '19 at 01:30
  • @zaitsman _[`MAF is a true addon framework`. You can separate your addons completely, even running them inside a `separate app domain` so that if an addon crashes, it won't take down your application.](https://stackoverflow.com/questions/835182/choosing-between-mef-and-maf-system-addin)_. –  Dec 03 '19 at 01:32
  • MAF is legacy though. – zaitsman Dec 03 '19 at 01:33
  • So is .NET Remoting and yet it is the _only_ mechanism **to this day** that supports inter-AppDomain communication within the **same** process without requiring TCP/pipes/WCF/REST or other relatively slow forms of comms. Robust plug-in frameworks rely on it –  Dec 03 '19 at 01:34
  • 1
    @zaitsman and its DI not _"IoC"_ –  Dec 03 '19 at 01:38
  • @MickyD you're right, i am wrong. What else? how's the weather where you're at? – zaitsman Dec 03 '19 at 01:39
  • [This q&a](https://stackoverflow.com/questions/9501604/ioc-di-why-do-i-have-to-reference-all-layers-assemblies-in-applications-entry) is related to yours because it discusses the concept of the Composition Root, which is the concept your beautiful application is missing. – Steven Dec 03 '19 at 07:39
  • 1
    @Steven - thanks for the link. I would like to accept it as an answer because it explains clearly why we have to reference the implementation libraries from the runnable top level projects. – mark Dec 04 '19 at 02:13

0 Answers0