How to deploy .NET core plugin application and avoid duplication of assemblies

Question

Following is a simplified version of what I want to acheive:

I have the the following .NET Core projects:

    Main -> Executable (Console Application)
    Plugin1 -> Class Library
    Plugin2 -> Class Library
    3rdPartyComponent -> Class Library

Plugin1 and Plugin2 both have dependency on 3rdPartyComponent. The Main executable has no dependencies on the plugins or 3rdPartyComponent. It loads the plugins using [Assembly.LoadFrom][1]. 

The deployment structure looks like below:

    MyApp    
     Main.exe        
     Plugins  
      -Plugin1  
      -Plugin2

Main.exe scans the Plugins folder and loads the available plugins. When the plugins are built, the third party library is duplicated for each of the plugin like below:

    MyApp
     Main.exe
     Plugins
      -Plugin1
       - Plugin1.dll
       - 3rdPartyComponent.dll
      - Plugin2
       - Plugin2.dll
       - 3rdPartyComponent.dll

How can these be built and deployed so there is only one copy of the 3rdPartyComponent.dll? Effectively like below:

    MyApp
     Main.exe
     3rdPartyComponent.dll
     Plugins
      - Plugin1
       - Plugin1.dll
      - Plugin2
       - Plugin2.dll

I need a solution which can be run using CLI.


In Java, I can do this by creating Main.jar, Plugin1.jar, Plugin2.jar, 3rdPartyComponent.jar with each jar file containing only the specific classes. I can then deploy and run the Main application something like:

    java -classpath plugin1/plugin1.jar;plugin2/plugin2.jar;3rdpartycomponent.jar -jar Main.jar

How can I do the above in .NET?

  [1]: https://learn.microsoft.com/en-us/dotnet/api/system.reflection.assembly.loadfrom?view=net-6.0

Answer 1

java supports remote references by url, but .net core does not. you will need to make this part of your deployment. the common dll's need to be copied to the application bin folder.

this also means the plugin must agree on the version. the main work around s to require plugin to dynamically load their dependent dll's. the plugin could have an init routine called with the folder the plugin was found, then the plug could load its dependencies.