我们正在使用 Windows Presentation Foundation 开发一个大型桌面应用程序。目前，该应用程序仅供内部使用，但最终将作为商业产品出售。我目前正在使用 M-V-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 桌面应用程序的信息。
是的，办公自动化模型仍然是实现流程外自动化的主要方式。最重要的是因为几乎所有语言都支持它。在 .NET 中实现起来并不容易，它不支持开箱即用的进程外 COM 激活。开始阅读此处了解如何使用 COM+ 进行操作。
是的，如果您的客户端是 .NET 应用程序，远程处理当然也可以工作。它并不完全过时，但实际上已被 WCF 取代。