C# 在远程处理期间使用事件更新GUI

我正试图了解.NET远程处理，试图在.NET中复制VB6 ActiveX EXE

到目前为止，我在服务器上实例化了一个所有客户端都可以共享的单例

singleton接受来自客户端的请求并验证数据，以事件的形式返回验证后的数据。这很好地工作——请求引用单例的类触发了它们的事件——也就是说，它们发送数据，接收经过验证的数据

但是，我需要一个接口。客户端托管在WPF应用程序中（服务器也是），当它们接收数据时，我需要更新显示（文本框、列表框等），以反映客户端和sinlgleton之间的通信

但是，一旦我添加了在mainform中实现的事件，以便客户端在收到Singleton的回复后调用，我就会遇到运行时错误，抱怨mainform没有序列化属性

为了保持简洁，我将描述以下过程

服务器使用以下代码运行：

            BinaryClientFormatterSinkProvider clientProvider = new BinaryClientFormatterSinkProvider();
            BinaryServerFormatterSinkProvider serverProvider = new BinaryServerFormatterSinkProvider();
            //
            IDictionary myDictionary = new Hashtable();
            myDictionary["name"] = String.Format("PracticonChannel_{0}", Port);
            myDictionary["typeFilterLevel"] = TypeFilterLevel.Full;
            myDictionary["port"] = Port.ToString();
            serverProvider.TypeFilterLevel = TypeFilterLevel.Full;

            http = new HttpChannel(myDictionary, clientProvider, serverProvider);

            // Register RemotingShared.SingletonObject as a 
            // Singleton Server-Activated type.
            RemotingConfiguration.RegisterWellKnownServiceType(
                typeof(Practicon.RemotingShared.UploadObjectSingleton), // Server-activated type
                "SingletonService",                     // objectUri
                WellKnownObjectMode.Singleton           // Singleton instancing mode
                );

            RemotingConfiguration.ApplicationName = " Upload Server";
            RemotingConfiguration.RegisterActivatedServiceType(
            typeof(Practicon.RemotingShared.UploadObjectSingleton));

客户端通过以下方式获得服务器激活的单例：

HttpChannel http1;
                // Set the formatters of the messages for delivery.
                BinaryClientFormatterSinkProvider clientProvider = new BinaryClientFormatterSinkProvider();
                BinaryServerFormatterSinkProvider serverProvider = new BinaryServerFormatterSinkProvider();
                //
                IDictionary myDictionary = new Hashtable();
                myDictionary["name"] = String.Format("PracticonChannel_{0}", Port);
                myDictionary["typeFilterLevel"] = TypeFilterLevel.Full;
                myDictionary["port"] = port.ToString();
                serverProvider.TypeFilterLevel = TypeFilterLevel.Full;
                http1 = new HttpChannel(myDictionary, clientProvider, serverProvider);

                ChannelServices.RegisterChannel(http1, false);


                uploadObj= (UploadObjectSingleton)Activator.GetObject(
                            typeof(UploadObjectSingleton),
                            fullAddress);

//---------- Here's the problem...
                uploadObj.ReplyEvent += new UploadObjectReplyEventHandler(OnUploadReply);

OnUploadReply是一个表单实现的事件，用于更新各种控件。当在运行时分配该属性时，由于mainform缺少Serialization属性，会发生序列化异常

---

这让我快发疯了。有人能给我演示/解释/告诉/说教/教训我如何更新用户界面以响应单例事件吗？

好的，答案是使用WCF。这并不像听起来那么可怕，我的解决方案比我想象的要好

我要向那些试图做我所面临的事情的人强调的是：

显然，创建一个服务器应用程序来承载服务，并且只承载服务。我试着做一些奇特的事情，比如使用服务器应用程序来维护服务状态的UI，它在做什么，为谁/为谁。不！。别这样

保持客户端和服务器之间的连接仅在需要时保持打开状态。再长一点，这个频道就有出错的风险，在花了好几个小时试图解决这个问题，试图从失败中恢复过来之后，你最好试着写一些关于如何放牧猫的说明。重新思考你的问题。打开，使用，关闭

无论如何，我必须想出一个ActiveX控件的替代品，它有一个用户界面。我创建了3个项目——服务器（用于托管）、客户机（用于为服务提供用户界面）、与服务交互的COM接口（称为函数、设置属性等）和外部应用程序

COM接口必须做的第一件事是尝试查找服务器的运行实例（顺便说一句，实现WPF应用程序的单个实例绝非易事，但这是离题的）

如果找不到，它会执行服务器应用程序，等待，然后打开一个频道。每次COM接口必须对话/等待接口时，都会重复此过程（显然，服务器应用程序只需运行一次）。球疼，但这避免了可怕的“通道处于故障状态”综合征。以前，我会发现该服务可以托管，并且一个频道可以在完全随机的时间段（1分钟、1小时、1天）内保持打开，但即使客户端/服务器什么都不做，故障也会发生。由于我的服务控制着北美（英国）的一条生产线，如果界面出现故障，在再次运行之前什么也做不了，所以我的首要任务是稳定性。到目前为止，“摇滚”和“硬”这两个词在我脑海里疯狂地浮现

所以，重复，打开，使用，关闭

希望这有帮助

嗯

---

顺便说一句，我对布拉姆的建议投了赞成票。

好的，答案是使用WCF。这并不像听起来那么可怕，我的解决方案比我想象的要好

我要向那些试图做我所面临的事情的人强调的是：

显然，创建一个服务器应用程序来承载服务，并且只承载服务。我试着做一些奇特的事情，比如使用服务器应用程序来维护服务状态的UI，它在做什么，为谁/为谁。不！。别这样

保持客户端和服务器之间的连接仅在需要时保持打开状态。再长一点，这个频道就有出错的风险，在花了好几个小时试图解决这个问题，试图从失败中恢复过来之后，你最好试着写一些关于如何放牧猫的说明。重新思考你的问题。打开，使用，关闭

无论如何，我必须想出一个ActiveX控件的替代品，它有一个用户界面。我创建了3个项目——服务器（用于托管）、客户机（用于为服务提供用户界面）、与服务交互的COM接口（称为函数、设置属性等）和外部应用程序

COM接口必须做的第一件事是尝试查找服务器的运行实例（顺便说一句，实现WPF应用程序的单个实例绝非易事，但这是离题的）

如果找不到，它会执行服务器应用程序，等待，然后打开一个频道。每次COM接口必须对话/等待接口时，都会重复此过程（显然，服务器应用程序只需运行一次）。球疼，但这避免了可怕的“通道处于故障状态”综合征。以前，我会发现该服务可以托管，并且一个频道可以在完全随机的时间段（1分钟、1小时、1天）内保持打开，但即使客户端/服务器什么都不做，故障也会发生。由于我的服务控制着北美（英国）的一条生产线，如果界面出现故障，在再次运行之前什么也做不了，所以我的首要任务是稳定性。到目前为止，“摇滚”和“硬”这两个词在我脑海里疯狂地浮现

所以，重复，打开，使用，关闭

希望这有帮助

M