如何在 WPF 桌面应用程序中开发公共 API 对象模型，以允许来自另一个 .NET 桌面应用程序的进程外自动化

Question

我们正在使用 Windows Presentation Foundation 开发一个大型桌面应用程序。目前，该应用程序供内部使用，但最终将作为商业产品出售。我目前正在使用 M-V-VM 设计模式的变体，以将尽可能多的代码保留在 UI 组件（即窗口、用户控件）之外。我知道在某些时候我们会想要公开一个公共 API 以允许客户扩展应用程序，甚至可能使用来自另一个 .NET 应用程序的公共 API 在进程外自动化应用程序。我没有太多为桌面应用程序设计公共 API 的经验，因此我正在寻找有关最佳做法的任何信息。

以下是我目前的一些问题：

1) 我如何设计 WPF 应用程序，使其能够从另一个运行在它自己的进程中的 .NET 应用程序在进程外自动运行？例如，假设客户正在运行一个控制台应用程序，他们希望自动打开 WPF 应用程序，然后在 WPF 应用程序中打开一个特定窗口。我不确定如何做到这一点。如果我有一个控制台应用程序正在运行并且我尝试通过代码创建我的 WPF 应用程序的一个新实例，我将收到以下错误：“无法在同一个 AppDomain 中创建多个 System.Windows.Application 实例”。我知道发生此错误是因为控制台应用程序不允许 WPF 应用程序在其当前的 AppDomain 中启动，但我真正想要的是 WPF 应用程序在它自己的进程中运行，而 .NET 控制台应用程序通过公共 API 控制它.

2) 我知道我的要求有点类似于 Excel 自动化，它使用 COM+ 允许 Excel 在进程外运行。但是，Excel 是用非托管代码编写的，我们的 WPF 应用程序显然是 100% 托管代码。我真的需要借助 COM+ 来允许通过来自另一个 .NET 应用程序的公共 API 对象模型在进程外控制 WPF 桌面应用程序吗？

3) 如果我想让我的应用程序通过公共 API 实现自动化，我应该研究 .NET Remoting 吗？或者，.NET Remoting 是否已经过时？

4) 我非常了解如何允许使用在运行时加载的动态加载项。但是，我仍然需要一个公共 API，加载项中的代码可以使用它来操作 WPF 应用程序。桌面应用程序的 API 设计有哪些好的资源？

感谢任何反馈。很难找到有关使用允许从另一个 .NET 应用程序自动化的公共 API 开发 .NET 桌面应用程序的信息。

谢谢， 克里斯。

Answer 1

是的，Office 自动化模型仍然是实现进程外自动化的主要方式。最重要的是因为几乎所有语言都支持它。在 .NET 中实现并不容易，它不支持开箱即用的进程外 COM 激活。开始reading here 了解如何使用 COM+ 来实现。

是的，如果您的客户端是 .NET 应用程序，远程处理当然也可以工作。它并没有完全过时，但实际上已被 WCF 取代。