目标
运行本地服务器 (WCF)，其中包含在计算机开机时跟踪信息的业务逻辑(在用户作为普通进程登录时运行)。包含表示逻辑的本地客户端 (WPF) 可以连接到随时可用的本地服务器，以将跟踪的信息呈现给最终用户。一切都是本地的和非关键的，安全不是问题。
实现
最初我基于被认为是遗留技术的Remoting技术编写了一个本地服务器，并将本地客户端连接到本地服务器。每个共享对象都是远程共享的，并且可以被调用。
问题
无法远程序列化 Lambda 表达式(启用折射器的属性名称绑定(bind))和事件。我知道可以使用启用远程的对象绑定(bind)事件并在服务器上调用它，但是，这会破坏 WPF 数据绑定(bind)。事件驱动编程很重要。
我寻求什么？
创建我提到的体系结构的示例，或者显示如何配置 WCF 使其以与 Remoting 类似的方式运行的基本示例。我能找到的所有在线资源(包括 MSDN 文章)都是为 .NET 2.0 编写的。自 .NET 2.0 以来，WCF 世界发生了很多变化，使用 .NET 4.0 是一项要求。甚至可以链接到示例、教程或文章以了解 .NET 4.0 中 WCF 的类似远程处理的行为!
最佳答案
WCF 是一项出色的技术，但是正如其他人所评论的那样，听起来您正试图违反 WCF 的核心原则。我在这里可能是错的，但听起来您想跨远程处理边界发送您的 View 模型？
在我看来跨远程处理边界发送 View 模型是错误的原因是架构原因。原因是我可能有多个客户端应用程序，即一个网站和一个 wpf 桌面应用程序。该 View 模型仅与 WPF 应用程序相关。它在很大程度上是特定于平台的(在大多数情况下)。由于 View 模型是特定于平台的，因此它们属于平台，而不属于您的服务。
您的 DTO 实体(即服务模型类)必须与您的 View 模型分开，因为您的 View 要求可能会在任何一个客户端应用程序上发生变化，并且您的服务可能希望在很大程度上提供与以前相同的服务。您的客户端应用程序可以依赖您的模型实体。我通常将它们放在我的服务项目和客户端应用项目通用的通用项目中。
这就是关于它的方式。一个好的设计应该允许任何人潜在地使用它并用它做他们想做的事。诸如 flikr、facebook 或 amazon 之类的 Web 服务不会告诉您如何或建议您应该在应用程序上显示哪些信息，您的应用程序也不应该。 (我不是提倡盲目跟随他们的设计，但这是一个社区示例，您可以看看)。
您的 View 模型应该通过实现 INotifyPropertyChanged 接口(interface)等默认使用可绑定(bind)数据类型，因此更新 View 模型上的数据应该是一件非常容易的事情。设计应用程序时最好的做法是思考，如果我做了一些不在我的功能列表中的事情，我会怎么做。我是否更难说，向公众公开我的服务(甚至认为这不是我的意图)。这将使您的设计保持稳健，并在客户改变主意时保持良好状态。
关于c# - WCF 行为配置作为 .NET Remoting，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/8527165/