Forcefully unloading AssemblyLoadContext
I'm building a plugin system for my WinUI 3 C# app. Currently, the plugin system uses an AssemblyLoadContext for each plugin, but I want to be able to unload the plugins on demand. ALC.Unload places the assembly in line for GC collection, but it doesn't actually unload the code until all event handlers are disconnected, and all running threads suspend. While this is usually a good thing, I need to be able to control the plugins on demand. In an environment like this, someone could easily create a malicious block of code that continues to run in the background without the user ever noticing; or, poorly written code could continue to run even if it wasn't intended to do so. Each plugin has a Shutdown method, and that is always called before the unload is requested, so plugins can gracefully shutdown and save data or do whatever else they need to do to ensure that user data isn't lost.
So, is there a way that I can force an ALC to unload the plugin right there and then instead of waiting for it to finish up what it's doing?
11 Replies
a malicious plugin could monkey patch the code that's supposed to unload it and prevent it that way too
you really don't have protection options once you're actually executing their code
I guess that’s fair. But for the second situation, poorly written code, how can I solve that? Like let’s say some dev is new to C# and they accidentally leave a timer running or something
But as far as they’re concerned, nothing is wrong with their code
It can cause memory issues too. If the plugin is never fully unloaded, then it’ll keep that instance; but, the UI thinks that the old instance is gone. So when the user turns the plugin on again, it creates another instance. You can create a ton of instances of the same plugin if they arent fully unloaded
I thought about that, but I’m not sure which IPC system is robust enough to provide the sort of communication that I need. The app follows the DI & MVVM design patterns, so, plugins also receive a slimmed down ServiceProvider that allows the plugin to access services from within the app. I don’t know how I’d do that over IPC
For context, this app is my custom shell. But, to make the shell extensible, I have to make a plugin system. As I mentioned above, the shell has services for things like the taskbar icons that external plugins should have access to.
You can have many of this.
And it's for .NET
Unloading is possible, yes.
Problem is, plugins should be able to host their own UIs, to create something on their own (for example, a plugin that adds desktop widgets). Id prefer if the UI was cohesive and seamless, so both ends should be using WinUI 3
Better than nothing :catshrug:
And it's up to the author of the plugin to make sure there is no memory leak. Don't use the plugin if that is the case.
Never depend on the author. Like I said in the original post, a new developer could write bad code and not know. The end users wouldn’t know either because there are a LOT of people who aren’t familiar with programming or computers as a whole who want to use GyroShell
I know if a plugin is bad, but GyroShell users would have no clue what’s going on
I guess I could just prompt the user to shutdown the app when a plugin unloads
unfortunate situation but I don’t want to mess with the runtime too much
Thank you all the help though
yeah