"Dynamic substitution" of plugins

Imagine a scenario in which our service system provides a range of functional services, and more new functional services will be added in the future, and there may be situations where functional services need to be changed or removed. A common basic requirement for such a service system is the operation of a service system that cannot be stopped when adding/removing/updating a feature service. In general, the encapsulation of each service into a single plug-in DLL makes it very easy to implement plug-in hot-swapping (see here for the basic information about plug-ins), but the plugin's "Hot Swap" ("Dynamic Substitution") is a problem. The reason is that when we unload the plug-in DLL from the service system, the service system still holds the underlying reference to the DLL, and if you try to delete or overwrite the dll,windows it will give you a message similar to "the DLL is being used."

So how to solve this problem? I think there are at least two options:
(1) Use the AppDomain. Load the plug-in in a new AppDomain, and then uninstall the AppDomain to cleanly unload the plug-in DLL from the AppDomain from the service system. The drawback of this scenario is the need to manage a large number of AppDomain (because you have a multitude of functional services), and the cross-AppDomain communication is done in a remoting way, which will introduce a lot of unnecessary trouble to our system. If you are interested, you can try this option, and I prefer the second one.

(2) Copy the plug-in DLL in memory, and then load the in-memory DLL. This way, the DLL on the hard disk can be overwritten or deleted arbitrarily. Previously we were loading the plug-in DLL directly from the hard disk, just like this:

Assembly asm = Assembly.LoadFrom (Addinfilepath);   

Now, we need to turn a corner:

Assembly asm  null  ;                                  // Copy the plug-in to the memory buffer first                byte NULL  ;                                     if (Filehelper.readfiletobuff (Addinfilepath, out addinstream))                {                    // load DLL in memory                }

This solves the problem of "dynamic substitution" of the plugin.

Reference Links:

"Dynamic substitution" of plugins

Enterprise-Class Server design and implementation experience of the plug-in System Foundation

"Dynamic substitution" of plugins