Note that there are some explanatory texts on larger screens.

plurals
  1. POHow to Develop a Public API Object Model In a WPF Desktop Application That Allows For Out-Of-Process Automation From Another .NET Desktop Application
    primarykey
    data
    text
    <p>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.</p> <p>Below are some questions I currently have:</p> <p>1) 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.</p> <p>2) 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?</p> <p>3) 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?</p> <p>4) 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? </p> <p>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.</p> <p>Thanks, Chris.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload