我们正在使用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）我理解我的要求与使用COM +允许Excel在进程外运行的Excel自动化有些相似。但是，Excel是用非托管代码编写的，我们的WPF应用程序显然是100％托管代码。我是否真的需要求助于COM +以允许WPF桌面应用程序通过另一个.NET应用程序的公共API对象模型进行进程外控制？
3）如果我想通过公共API允许我的应用程序自动化，我应该研究.NET Remoting吗？或者，.NET Remoting被认为是过时的吗？
4）我非常了解如何允许使用在运行时加载的动态加载项。但是，我仍然需要一个公共API，加载项中的代码可以用来操作WPF应用程序。有关桌面应用程序API设计的一些优秀资源是什么？
我感谢任何反馈。很难找到有关使用允许从其他.NET应用程序进行自动化的公共API开发.NET桌面应用程序的信息。
谢谢， 克里斯。
答案 0 :(得分：0)
是的，Office自动化模型仍然是实施进程外自动化的主要方式。最重要的是因为几乎任何语言都支持它。在.NET中实现并不容易，它不支持开箱即用的进程外COM激活。启动reading here以了解如何使用COM +。
是的，如果您的客户端是.NET应用程序，Remoting肯定会起作用。它并没有完全过时，但已被WCF取代。