.net - open - whatsapp meta tags
Implementing untrusted plugins in.NET web application (2)
It looks like your primary concern is isolation (for security as well as for robustness).
As such your best option here is to activate your addin in a separate AppDomain. Within this domain you can control what assemblies you would allow to be loaded (see AppDomainSetup class).
Your main code will be also protected from anything untoward happening inside a plugin: All the plugin methods will have to work with are copies of the core objects (unless objects you pass over are inherited from MarshalByRefObject, in which case all bets are off). The exceptions in the addin methods can be handled by wrapping all calls in try except, or through AppDomain's UnhandledExcption event.
Keep in mind that there is a performance penalty for crossing the AppDomain boundaries. The call is essentially a remoting call.
Another potential problem is how do you plan to manage the AppDomains. I never tried to create more than a few AppDomains in a process, but I would expect trouble here. Combining Addins for multiple users in a single domain wold challenge the protection you are trying to build into this
In response to @RationalGeek question - UnhandledException event allows to do that - sort of. You can subscribe to this event in both your core domain as well as the plugin domain, but there is a lot of uncertainties in doing it this way - see the article I referenced for more details. May be a better option would be to wrap every call to your API in try/except
I'd like to develop an application that accepts plugins from the user community, similar to how Chrome or Firefox does. This would be a web application, so each "instance" of the application for individual users would run different plugins (plugins would be loaded as singleton instances, but would be "active" only for certain users). I'm planning on implementing the application in .NET, and trying to come up with an architecture for the plugin model.
Here are my desired attributes:
- Plugins are built entirely outside of my core application, as separate assemblies.
- Plugins run in their own "locked down", low-trust environment. Probably a separate AppDomain.
- Plugins can only act through an API that I provide. E.g. I will pass them some sort of facade as an interface, and they can only call to that, not call to any other assemblies. I can't have plugins that can arbitrarily take actions on the web server, e.g. affect the file system.
- A fatal crash in the addin cannot affect the stability of the core application.
It seems like System.AddIn is my best bet, but I am unclear on how I can force the loaded addins to only work through the API that I provide, and not load any other assemblies. Does System.AddIn provide that functionality? Also, can System.AddIn be used with ASP.NET / IIS?
What other options do I have besides System.Addin?
Why not just use reflection and discover available plug-ins at run time? Assembly.LoadFile to get assembly, GetExportedTypes to get your objects Create an instance with Activator.CreateInstance
Then just run the plug-in in a try loop to make sure it does not affect the system. Though you will need some significant architecture to provide actual stability.
Stay away from MEF unless you have complex scenarios for plug-in management. If it's just allowing users to use theirs and including a few of your own, just use reflection.