Comments by VENKATHEGDE (Top 4 by date)

Thank you for clarifying the usage of Threading Models and AppDomains - Very Enlightening...

In the code Snippet above:

//plugin-code of the implemented plug-in interface:
Control[] IControlPlugin.AddControls(DockPanel parent) {

DockPanel has to be serializable or should inherit from MarshalByRefObject if the method call crosses AppDomain Boundaries and neither of it can be true.

When Making the call from the host application,
IControlPlugin.AddControls(DockPanel parent)
It will use Remoting and try to Marshal DockPanel (As it is an Argument in the method) and will fail.


Kindly confirm if my understanding about DockPanel not being marshalable / proxied is correct.

Thanks again, for helping me out.

--
Regards,
ven.

Thanks for your reply, Again.

I will try to explain my problem:

The plugins are the widgets of the application (Different kinds, each for which the App will create a contract).

The Unloading/Reloading of the plugin will be used to fix defects on the fly. I will also be able to incorporate new features without bringing down the host application.

Regarding "AppDomain is transparent to threads", In a marshalbyRefObject scenario, The app thread stops at the AppDomain boundary, and another thread in the other appDomain calls the method. The calling thread is blocked until the Remote Object returns control. In a GUI environment, the Dispatcher thread is One per process. AppDomains do not share threads. Is my UserControl hooked to its own dispacther Or the Host Application's dispatcher ?

If I were to use the meta data approach, Are you suggesting that the host build the UI based on the meta data?

My issues and doubts circulate around GUI issues. I have stated two specific scenarios as integration issues (Posed as two questions) between the WPF container and the Plugin as I see it.

Say for example, My App is a WPF app, and my Plugin will reside in a Dockable panel. first Question is: How do I add the Plugin into my WPF container ? The UserControl does not inherit from MarshalByRefObject and hence cannot have a remoting object. The Serializable won't work either. So,

Question 1: How do I add a UserControl that has GUI (and data model) to the Host WPF app?

After adding the UserConrol, I want to have seamless focus between Host and Plugin. Say I have 3 plugins (A, B, C) in one Dockable window and two plugins (D, E) in another dockable window.

Question 2: How do I seamlessly tab from A, B, C, D to E across Dockable Windows? (I need to have host and Plugin Co-ordination)

Thank you very much for your valuable time.
And Thank you for all the help and expertise that you are providing.

--
regards,
ven.

Thank You SAKryukov for your answer. But I feel somewhat dry...

It is understood as to how a Plugin Architecture can be created. There is a great article by Daniel moth on MAF:
http://www.danielmoth.com/Blog/maf-screencasts.aspx
and the book by Jeffery Ritcher gives details about AppDomains.

I can create a base interface and find types from DLLs. In addition to that, I also learned that the DLL locking problem can be resolved, by using Load() APIs that take a bytestream (Two bytestreams if You want to provide PDB info) which eliminates the DLL locking issue.

By not maintaining references to any of the classes, and maintaining my own queues, I can register and unregister plugins for processing requests, making them eligible for unloading when I call AppDomain.unload(...), whenever I have to replace a Plugin on the fly.

The implementation would work with Data Classes, The issues start showing up when we start doing the same with GUI

Window Focus traversal and interception, Combined Context menu [App + Plugin] are the issues I am expecting, and need answers for them.

I looked at WPF add-in architecture as well. But this has limitations (http://msdn.microsoft.com/en-us/library/bb909794.aspx#WPFAddInModelLimitations[^]). I would like to know if somebody was able to overcome them by using any workaround.

How do you access and listen to each WPF Dispatcher thread, if they are separate apps loaded vi ExecuteAssembly()?

GUI issues can become frustrating as focus issues alone can take a toll on you if the components cannot have communication (Lost Focus / Gained Focus like issues => If, for example, Every focused component has a RED Border around it, It would be inconsistent If TWO components have Red Borders within the same application.]

--
regards,
Ven.