Обновление GUI во время переадресации с событиями

Question

Я пытаюсь разобраться с удалением .NET в попытке репликации в .NET VB6 ActiveX EXE.

До сих пор у меня есть однострочный экземпляр, созданный на сервере, с которым могут делиться все клиенты.

Singleton принимает запросы от клиентов и проверяет данные, возвращая проверенные данные в форме события. Это хорошо работает - классы, которые запрашивают ссылку на Singleton, активируют свои события, т. Е. Отправляют данные, получают подтвержденные данные.

Однако мне нужен интерфейс. Клиенты размещаются в приложении WPF (сервер тоже), и когда они получают данные, мне нужно обновить отображение (текстовое поле, список, что угодно), чтобы отразить связь между клиентами и синглглтоном.

Однако, как только я добавляю событие, реализованное в основной форме для вызова клиентом, как только он получил ответ от Singleton, я сталкиваюсь с ошибками во время выполнения, жалуясь, что основная форма не имеет атрибутов сериализации ....

Чтобы сохранить это сжатый я опишу процесс следующим образом

сервера работает с кодом:

  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 - это событие, реализованное в форме, которое обновляет различные элементы управления. Когда это назначено во время выполнения, исключения Сериализации происходят из-за того, что основная форма не имеет атрибута сериализации.

Это сводит меня с ума. Может ли кто-нибудь показать/объяснить/рассказать/проповедовать/читать лекции о том, как я обновляю пользовательский интерфейс в ответ на события, выпущенные в одиночном режиме?

Answer 1

ОК, ну, ответ на этот вопрос - использовать WCF. Это не так страшно, как кажется, и мое решение работает лучше, чем я мог ожидать.

То, что я хотел бы подчеркнуть, чтобы кто-то пытается сделать то, что я столкнулся с искробезопасным являются:

1. Очевидно, что создать серверное приложение для размещения и только HOST обслуживание. Я пробовал делать причудливые вещи, такие как использование серверного приложения, чтобы поддерживать пользовательский интерфейс для службы - статус, что он делает и кому/кому. Незнаю !. Просто не.

2. Держите соединение открытым между клиентом и сервером открытым, ТОЛЬКО, насколько это необходимо. Дольше и канал рискует ошибиться, и после многих часов, пытаясь разобраться в этом, пытаясь оправиться от сбоя, вам лучше попытаться написать инструкции о том, как стадным кошкам. Переосмыслите свою проблему. Открыть, использовать, закрыть.

3. В любом случае мне пришлось придумать замену элемента управления ActiveX, имеющего пользовательский интерфейс. Я создал 3 проекта - сервер (для хостинга), клиент (для предоставления пользовательского интерфейса для службы) и COM-интерфейс, взаимодействовавший с сервисом (называемый функциями, набор свойств и т. Д.) И внешнее приложение.

Первое, что интерфейс COM должен был сделать, чтобы попытаться найти запущенный экземпляр сервера (кстати, реализует один экземпляр приложения WPF отнюдь не простой подвиг, но это от topic)

Если не удалось найти, оно выполнило приложение Server, ждало, а затем открывало канал. Этот процесс повторялся каждый раз, когда COM-интерфейс должен был говорить/ждать интерфейса (очевидно, приложение Server нужно было запускать только один раз). Боли в шаре, но это избегало синдрома страшного «канала в неисправном состоянии». Раньше я бы нашел, что услуга может быть размещена, а канал открыт для ПОЛНОГО случайного количества времени - 1 минута, час, день, но ошибка произойдет, даже если клиент/сервер ничего не делает. Поскольку моя служба контролирует производственную линию в Северной Америке (из Великобритании), и если интерфейс идет вниз, НИЧЕГО не делается, пока он не работает снова, моим приоритетом была стабильность. Таким образом, слова «скала» и «жесткие» в бреду приходят в голову

Итак, чтобы повторять, открывать, использовать, закрывать.

Надеюсь, это поможет.

MM

КСТАТИ Я upvoted предложения Блама в.