如何在 WPF 桌面应用程序中开发公共 API 对象模型，以允许从另一个 .NET 桌面应用程序进行进程外自动化
我们正在使用 Windows Presentation Foundation 开发一个大型桌面应用程序。目前，该应用程序仅供内部使用，但最终将作为商业产品出售。我目前正在使用 MV-VM 设计模式的变体，以将尽可能多的代码保留在 UI 组件（即窗口、用户控件）之外。我知道在某些时候我们会想要公开一个公共 API，以允许客户扩展应用程序，甚至可能使用另一个 .NET 应用程序中的公共 API 在进程外自动化应用程序。我没有太多为桌面应用程序设计公共 API 的经验，因此我正在寻找有关最佳实践的任何信息。
以下是我当前遇到的一些问题：
如何设计 WPF 应用程序，使其能够在其自己进程中运行的另一个 .NET 应用程序中实现进程外自动化？例如，假设客户正在运行一个控制台应用程序，他们希望自动打开 WPF 应用程序，然后在 WPF 应用程序中打开特定窗口。我不确定如何实现这一点。如果我正在运行一个控制台应用程序，并且尝试通过代码创建 WPF 应用程序的新实例，我将收到以下错误：
<块引用>“无法在同一 AppDomain 中创建多个 System.Windows.Application 实例”。
我知道发生此错误是因为控制台应用程序不允许 WPF 应用程序在其当前的 AppDomain 中启动，但我真正想要的是 WPF 应用程序在其自己的进程中运行，而 .NET 控制台应用程序通过控制它公共 API。
我知道我的要求有点类似于 Excel 自动化，它使用 COM+ 来允许 Excel 在进程外运行。然而，Excel 是用非托管代码编写的，而我们的 WPF 应用程序显然是 100% 托管代码。我真的需要求助于 COM+ 来允许通过另一个 .NET 应用程序的公共 API 对象模型对 WPF 桌面应用程序进行进程外控制吗？
如果我想让我的应用程序通过公共 API 实现自动化，我是否应该考虑 .NET Remoting？或者，.NET Remoting 是否已被视为过时？
我非常了解如何允许使用在运行时加载的动态加载项。但是，我仍然需要一个公共 API，加载项中的代码可以使用该 API 来操作 WPF 应用程序。关于桌面应用程序 API 设计有哪些好的资源？
我很感激任何反馈。很难找到有关使用允许从另一个 .NET 应用程序进行自动化的公共 API 开发 .NET 桌面应用程序的信息。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
是的，办公自动化模型仍然是实现流程外自动化的主要方式。最重要的是因为几乎所有语言都支持它。在 .NET 中实现起来并不容易，它不支持开箱即用的进程外 COM 激活。请开始阅读此处了解如何使用 COM+ 来完成。
是的，如果您的客户端是 .NET 应用程序，远程处理当然也可以工作。它并不完全过时，但实际上已被 WCF 取代。
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.