Is there any way to block a C# plugin from accessing the main C# Application in a program?

Question

I have a program and a simple plugin architecture where the plugins implement a generic interface and the main program loads all plugins that implement this interface. It's the most common custom plugin architecture I have found so far, so that's what I'm using.

I am not using Microsoft's MEF and I have my reasons for not doing so. I'll leave it at that.

The issue is that when the plugins are loaded, no matter how 'blind' they are to the main program and it's forms/classes/etc. it can still access System.Windows.Forms.Application and can therefore gain access to my application and its currently running forms/methods/controls/etc.

I do not want this. Is there an way to restrict a plugin's access to the main Application?

EDIT: More info about the plugin

We (my boss and I) are currently discussing what the plugins need to do. They all obviously need to add functionality, but we originally decided to give each plugin access to the currently running form so that it can add controls and events directly to the form. This was based on the assumption that only we, the developers, would be writing them.

Now we are considering the possibility of third party plugins and the original design, obviously, has about as much security as a "Do Not Enter" sign on an open door with no one around.

Or a "Take One" sign hanging on a bowl of individual skittles on Halloween.

Answer 1

One way of doing this is to host your plugins in their own AppDomains. You can configure these AppDomains to have limited security to prevent them from accessing resources in the main AppDomain. This does complicate things a lot, but will give you the sand-boxing you're after.

An additional benefit you receive from AppDomain hosting is that you can load and unload these domains if you wish to refresh plugins, plus you can protect your main AppDomain from crashes in your "child" domains.

Update

After seeing your update re. the capabilities of your plugin, AppDomains are not going to help if your plugin must have direct access to UI elements e.g. access to a form to add controls. You will not be able to give direct access to a form over an AppDomain boundary, or produce controls in one AppDomain and then marshal them across to another.

You could still consider hosting plugins in another AppDomain, but you will need to think about some sort of proxy mechanism so that actions like adding a control to a form can be done on behalf of a plugin, rather than letting the plugin access the form directly. For instance, you could pass in a form builder object which had methods such as AddButton. The proxy could then perform these actions of behalf of the plugin in the main domain. In this way you could provide a limited API for the plugin complete with required events.

This approach is by no means trivial, but once you have mastered the basics it's not too complicated.

Update 2

Things have moved on since rolling your own plugin frameworks with AppDomins back in the day. There is now support baked into the .Net framework since 3.5 for plugins:

MAF - Managed Addin Framework / System.Addin

It supports AppDomain isolation modes for plugins and has plugin loaders, etc. No need to roll your own.

Answer 2

If you can run your plugins in their own AppDomains, that would certainly increase the level of isolation. It can also make it a pain to communicate with them though. Without knowing more about what the plugins are meant to do, it's hard to know whether or not that's appropriate.