WPF GUI plugin design. I need a lil' feedback

Question

Hi all

I'm involved in a project which is able to connect to different hardware devices on the fly. We've been assigned to make a Touch Screen GUI so we have a MMI to the devices.

As any device (and any type of device) potentially can connect to our framework, we've decided to let 3rd party device developers make their own GUI plugin. All is fine and dandy this far :)

The real problem is, that our manager wants these GUIs to be able to execute some forms of control flows, and he dont want us to have our own DSL - So, as we're doing the GUI in WPF, they must be able to execute MSIL. This is a huge security threat, and I've told him that, but as it's a prototype, he says it's fine. Alrighty, fine it is.
There's another problem though - Arbitrary MSIL might crash or deadlock, so we need to host it in some sort of async context. Since WPF doesn't allow more than one thread to access the GUI, we've goit ourselves a complex scenario..

So far, I've been rather short on ideas on how to solve this. My best bet is to split the GUI part and the code part into 2 things: Raw Xaml for the GUI, and MSIL hosted in another thread for the code. I then need to create a facade (On runtime?) to link the GUI and the MSIL together by sending calls to each others threads.
I can do this, not a problem, but I think it's really smelly. You're forcing other developers to use MVVM without code behind, I'm unsure if I can support all bindings, and I don't like that the View and the ViewModel are in seperate threads (Well, I don't mind it, but I'm unsure if it could cause problems, since this design would be very transparent to the plugin developer, so he prolly wouldn't consider making stuff threadsafe).

Does anyone have any ideas on how to design this? Or thoughts on the requirements? Any kind of feedback would be nice :)

Thanks in advance :)

Answer 1

There might be a middle road here- your boss doesn't want you to create your own DSL, but how about an existing dynamic language like IronPython/IronRuby?

Not sure if that would give you the flexibility you're looking for but it's worth looking into. I agree that allowing MSIL to be injected is hacky. I'm not sure separating your Views and ViewModels into separate threads will work at all, to say nothing of work cleanly.

Answer 2

If you want to do it 'right'; Have a look at hosting the plugins in separate app domains. Set security levels on those app domains from the hosting app and communicate with well-defined channels.

If you want to get it done; Use the MEF. Nothing beats that pattern for plugin architecture.

Hope this helped and good luck!

Answer 3

I'll try and give you a different answer. Unfortunately I don't think you are going to have an easy time of it. It DOES sound interesting though :)

• Host your plugins in separate applications by using some kind of app starting code which you control.
• Use this mechanism to set up the security the way you want it (disallow access to filesystem, internet, etc)
• Use WCF with local-computer binary mode for communication. You were going to provide some kind of API anyway so this will probably not add too much overhead from what you would have done.
• Host the plugins in a window with no border and position it manually over your main application window. (I used to work on a project where we did this with a few Office apps. It can work remarkably well) You will probably spend the most time getting this right. Some little hacker is going to feel like a hero though! :)
• Do some resource sharing on the DLL level (UI skinning, look and feel, common controls and what-not)