I'm developing a desktop application in .Net that follows a plugin architecture, something like this:-
I have a "core" .Net solution, containing the desktop exe project, and a handful of class library projects. These classes provide all sorts of shared/common functionality, and are referenced by the application exe and individual modules.
Each module lives in its own .Net solution. The solution has its own copy of the above shared library DLLs that the module's project(s) reference.
End-user installation really just involves deploying the core exe & DLLs, along with the modules' DLLs required at that site, into one folder. I've got no problem with the mechanism used by the core exe to "discover" which modules are present, then load & initialise them.
My concerns are around managing and deploying the DLLs. In an ideal world I should be able to make a change to "module X" and redeploy just that module's DLLs. However it's feasible that a change may also involve updating one of the shared libraries. When I redeploy these updated DLLs, the updated shared library functionality could break other modules (or even the application exe) that reference it. I guess what I should be doing in this scenario is to rebuild/redeploy all solutions, not just "module X".
An easier approach may be to treat the "core" and all modules as a single product, and redeploy everything in every release, even if it's just a change to one module. But it feels like I would be losing one of the advantages of a plugin architecture - I should be able to release a new version of a module in isolation.
Any thoughts? Or are such DLL referencing issues an unavoidable part of using a plugin architecture?