We're developing a large desktop application using Windows Presentation Foundation. Currently, the application is for internal use but will eventually be sold as a commercial product. I'm currently using a variation of the M-V-VM design pattern to keep as much code out of the UI components (i.e. windows, user controls). I know at some point we are going to want to expose a public API to allow customers to extend the application, and maybe even automate the application out-of-process using the public API from another .NET application. I don't have a lot of experience designing a public API for a desktop application, so I'm looking for any information regarding best practices.
Below are some questions I currently have:
How do I design the WPF application to be able to be automated out-of-process from another .NET application running in it's own process? For example, say a customer has a console application running and they want to automate the opening of the WPF application and then open a specific window in the WPF application. I'm not sure how this can be accomplished. If I have a console app running and I try to create a new instance of my WPF application through code I'll get the following error:
"Cannot create more than one System.Windows.Application instance in the same AppDomain".
I understand this error occurs because the console app won't allow the WPF application to start in it's current AppDomain, but what I really want is the WPF application to run in it's own process while the .NET console application controls it via the public API.
I understand what I am asking is somewhat similar to Excel automation which is using COM+ to allow Excel to run out-of-process. However, Excel is written in unmanaged code and our WPF application is obviously 100% managed code. Would I really need to resort to COM+ to allow a WPF desktop application be controlled out-of-process via a public API object model from another .NET application?
If I want to allow my application to be automated through a public API, should I be looking into .NET Remoting? Or, is .NET Remoting considered obsolete?
I have a good understanding how to allow the use of dynamic add-ins that are loaded at run-time. However, I'll still need to have a public API that the code in the add-ins can use to manipulate the WPF application. What are some good resources on API design for desktop applications?
I appreciate any feedback. It's been very difficult to find information on developing a .NET desktop application with a public API that allows automation from another .NET application.
Yes, the Office automation model is still the dominant way to implement out-of-process automation. Most of all because just about any language supports it. It is not that easy to implement in .NET, it doesn't support out-of-process COM activation out of the box. Start reading here to find out how to do it with COM+.
Yes, Remoting certainly would work too if your client is a .NET app. It isn't exactly obsolete but it has effectively been replaced by WCF.