In the past I developed a program (targeting .net Framework 4.7.2) to be used as a plugin of another one of which I have no control. All worked fine until the main program switched to .Net Standard 2.0. The problem is related to some components such as System.Windows.Forms.DataVisualization.Charting.Chart
which are not correctly supported anymore on this new version of the .net infrastructure.
I would like to better separate the two programs in order to avoid disruptive effects whenever the main program changes technology. I think to split the plugin in two parts:
- the first one will be simply a sort of facade between the main program and the real plugin,
- the second one is the real plugin with its GUI and business logic (using .net Framework 472).
Now the question is: what could be the best way to have these parts to communicate?
It would be ideal to have also the facade targeting net472 as currently is.
The solutions that come to my mind are an out of process COM server for the real plugin or something like IPC or pipes.
I already tried to expose a COM interface from the “real” plugin and to reference it from the facade but this gave the same effect as not splitting the plugin at all, because no COM server is created in this way I think.
Creating a new process from the facade works in the sense that the old components are displayed correctly, but then the real plugin has to send commands to the facade and receive data in return.
If COM is the solution it seems to me that I need to export an interface from both the facade part and the real part. I found this example example
Is it the way to go or there is something better or simpler?