1

enter image description here

I have a few .NET apps where 90% of the codebase is virtually identical. I plan to pull this code out into a shared library, which all apps would then reference and make use of.

But what I really need is the inverse of this. Each of my apps consist of just 1 or 2 interface implementations which should simply 'plugin' to the shared code. They don't need their own Main() methods or entry points, the shared code can have all the logic to start things up and run, then each app just plugs in its own app-specific dependencies.

It therefore feels like some kind of plugin approach is better than a library approach. I don't want my apps to all call out to a shared library, I want that ("executable library") to call out to my apps, as discussed here: https://www.c-sharpcorner.com/UploadFile/a85b23/framework-vs-library/

Is this approach possible in .NET Core? How would this be achieved?

FBryant87
  • 4,273
  • 2
  • 44
  • 72
  • 1
    Possibly looking for something like this - https://medium.com/@nativoplus/plugin-architecture-in-asp-net-core-1e5b9c2fe7f4 – adityap Sep 19 '18 at 21:53
  • Possible duplicate of [ASP.NET Core 1 Modular (Plugin) Architecture?](https://stackoverflow.com/questions/36154649/asp-net-core-1-modular-plugin-architecture) – adityap Sep 19 '18 at 21:54
  • So is there no simple built-in way to achieve this? It looks substantially more complicated than just referencing a library if third party frameworks are needed. ExtCore looks very useful though. – FBryant87 Sep 19 '18 at 21:58
  • 1
    Not that I know of. What you are trying to achieve is a specific pattern/architecture for your app which can be achieved by either implementing one of the existing ones or writing you own – adityap Sep 19 '18 at 22:02
  • 1
    @FBryant87 Note different plugin frameworks implement compile time or runtime pluggability. Loading plugins at runtime is usually more complicated, but is the more common use of the term "plugin" which is probably not what you need. If you look at ASP.NET MVC structure of global.asax, you'll see you still have to setup calls to the frameworks methods to register routes, enable logging, etc. You could build a library that factors out the common code, but you still create a project/app for each of your apps, but you call something like SharedLibrary.Startup(new BobsSpecificApp()) from main. – AaronLS Sep 19 '18 at 22:05
  • With more details about what are the common denominators for these apps are, we could probably make more specific architectural suggestions. – AaronLS Sep 19 '18 at 22:06
  • The 90% shared code is logic for consuming Kafka messages, so it makes sense to move this into some kind of Consumer app/library/framework. The app-specific parts in other apps are then just message handlers for what to do when a message is consumed, so many apps across the board will make use of the Consumer. That's why it feels wrong to make the Consumer a library, because the apps just need to implement IMessageHandler, and nothing more. They're plugins in this sense, they don't need startup code. – FBryant87 Sep 19 '18 at 22:11
  • 1
    And MEF (System.Composition) ? [sample here](https://www.tutorialspoint.com/dotnet_core/dotnet_core_managed_extensibility_framework.htm] – Kalten Sep 19 '18 at 22:16

0 Answers0