0

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

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

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

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

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

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

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

谢谢，克里斯。

4

1 回答 1

0

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

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

于 2010-01-26T15:27:43.063 回答