The problem is that we are using both types of plugins: delphi and .net. Delphi plugins are destroyed the moment I call THYModuleManager.FreeInstance(…).
With .net plugins that does not happen. All allocated resources (including custom controls, labels, panels etc.) don’t get released and after about 2 hours of running, the application memory usage increases from ~80MB to ~650MB and at that point (depending on available memory in a machine) it crashes.
Also I already have custom variables clean-up based on the HostChanged event, where I check if Host property is null and release my custom non-visual variables. The visual controls should be disposed/freed by the dispose/finalization code of the plugin.
This application I’m working on is part of a CCTV surveillance system and needs to be operational 24/7. Each new DLL module is a driver for separate vendor. Some vendors have SDK’s based on COM, while others are made in .NET.
The problem here is that the way plugins work now is inconsistent: delphi plugins get freed the moment I call THYModuleManager.FreeInstance(…), while .NET plugins wait until I call THYModuleManager.UnloadModule(…). Our application initially was developed in Delphi, but later we had to add .NET plugins support. We did not expect that they would be designed differently. Also we can’t unload the entire module to free a single plugin, because at the same time there might be lots of other plugins open (from the same module).