WPF/WinForms Хостинг (встраивание) окна чужого win32 приложения.

Ссылка на пример из статьи:

Хочу поделиться с вами способом, как можно окно внешнего приложение "встроить" в свою программу. Ситуация из жизни: разрабатывая CRM систему для заказчика может появиться потребность, в одном из сценариев обслуживания, дать пользователю возможность произвести какие то манипуляции во внешней системе. Если эта система является Web сайтом, то задача решается добавлением WebBrowser на форму. Но представьте, что это какое то приложение, и что тогда делать?
Для этого можно провернуть трюк используя WinAPI, в результате которого окно внешнего приложения окажется "внутри" нашего (как будто экран виртуальной машиной), но у заказчика будет складываться иллюзия того, что мы его запустили внутри нашего приложения. И это похоже на магию.

В примере, ссылка на который имеется в начале статьи, я добавил TabControl, у которого на вкладках размещены три стандартных Windows приложения:

• Notepad - блокнот.
• Write - простой редактор документов.
• Regedit - редактор реестра.

Если запустить пример и переключать закладки, то можно увидеть приведённый на скриншотах ниже, результат работы:

Блокнот:

WCF. Callback через BasicHttpBinding без дуплексной связи.

Оглавление:

1. WCF service. С чего начать. Основные моменты создание службы. 
2. WCF. Callback через BasicHttpBinding без дуплексной связи.
3. Realtime WCF Tracker вызовов клиентского приложения.
4. Как отключить публикацию метаданных mex WCF сервисом. 

В данной статье я хочу поделиться с вами примером того, как можно в WCF инициировать передачу данных с сервера на клиент используемые BasicHttpBinding в качестве привязки для взаимодействия.
Как вам должно быть известно, для того, что бы сервер выступа в качестве инициатора передачи данных на клиент используя WCF, ему надо использовать одну из схем ниже:

• Производить подключение к клиенту самостоятельно в ответ на вызов клиента (что выглядит глупо).
• Использовать Duplex связь, которая была создана специально для этого.
  

  [ServiceContract(CallbackContract = typeof(ICallback))]
  internal interface IMyContract
  {
  }

Duplex связь покрывает наши запросы, но есть одно "но" - привязка (Binding) должена поддерживать работу с использованием сессии. А BasicHttpBinding (на основе протокола HTTP) в силу своей природы не может поддерживать сессию (постоянное TCP соединение), так как работает по схеме "Запрос-ответ". Как же тогда поступить?

WSDualHttpBinding привязка.

Для работы через HTTP транспорт, с возможностью использования Duplex связи, специально был создан WSDualHttpBinding, который, для имитации сессии, используя HTTP заголовок, добавляя туда техническую информацию. А для обратного соединения сам создаёт подключение к клиенту. Замечу, что обратное соединение создаётся через WCF engine, и используется как при работе с любой другой привязкой, а не программистом, при первом подключении клиента. В качестве обратного соединения используются подключения на 80 (по умолчанию) порт клиента со стороны сервера, когда надо передать данные.
Все было бы хорошо, но в какой то момент, может возникнуть ситуация, когда клиент будет находиться за NAT, что приводит к невозможности подключиться к нему сервером. Почему? Читайте как работает NAT, он разрешает соединения из внутренней сети, но запрещает подключения из внешней (за маршрутизатором).  В это случае выходом может быть лишь привязки на основе протокола TCP (NetTcpBinding), в которые, для обратного и прямого соединения, используется одно TCP соединение. Но что, если нам нужно как то через HTTP производить обратный вызов клиента.

WCF service. С чего начать. Основные моменты создание службы.

Примеры, которые используются тут, можно скачать по ссылке:

Еще ссылки:

1. WCF service. С чего начать. Основные моменты создание службы. 
2. WCF. Callback через BasicHttpBinding без дуплексной связи.
3. Realtime WCF Tracker вызовов клиентского приложения.
4. Как отключить публикацию метаданных mex WCF сервисом.  

Оглавление статьи:

1. Что такое endpoint?
2.  Способы общения клиента с сервисом. 
3. Канал связи клиента и сервера.  
4. Надежные каналы связи (reliableSession).
5. Управление состоянием службы.
6. Управление созданием экземпляров службы.
7. Управление временем жизни экземпляра службы атрибутами контракта.
8. Режимы параллельной работы с экземплярами службы
9. Регулирование нагрузки.
10. Обработка исключений.  
11. Обработка исключений. Продолжение работы с посредником если используется HTTP транспорт.
12. Обработка исключений. Обертывание всех исключений в FaultException, используя IErrorHandler.
13. Закрытие канала посредника.
14. Использование общей сборки с контрактами.
15. Как убрать Web Reference. Использование общей сборки с контрактами.

Введение

В данной статье хочу описать настройки, которые разработчику следует знать  перед началом создания сервиса и клиента к нему. Я исхожу из того, что читатель уже имеет представление о WCF, пользовался какими то наработками, но не углублялся в настройки Binding и сервиса.

• Если вы являетесь новичком и хотели бы увидеть примеры служб и работу с ними, перед прочтением советую скачать и посмотреть примеры Windows Communication Foundation (WCF) and Windows Workflow Foundation (WF) Samples for .NET Framework 4/ созданные Microsoft.
• Из книг советую читать "Создание служб WCF (Джувел Леве)", на основе которой, а так же собственном опыте будет писаться данная статья.
• Для демонстрации можно использовать мои примеры из проекта, ссылка на который в начале статьи. 

Я не буду расписывать все процессы создания с нуля. Тут будет представлены только наиболее интересные, на мой взгляд, понятия и настройки, о которых узнал после прочтения книги, просмотра описаний на msdn и написании примеров для демонстрации.
По каждой теме я старался не просто написать определение, а сделать реальный пример с демонстрацией, что бы все стало ясно.

Основные понятия и настройки.

Что такое endpoint?

Конечной точкой называется совокупность трех элементов:

1. Адрес сервиса. Подразумевается, что это URL, по которому располагается сам сервис.
2. Контракт сервиса.
3. Binding - содержит настройки работы с сервисом, протокол взаимодействия, Timeouts операций и т.д.

Способы общения клиента с сервисом.

В WCF существует три способа общения, которые обязательно надо знать:

1. Request-reply (запрос-ответ) - это когда с клиента делает вызов метода контракта Method(), текущий поток останавливается и ждет, пока сервер обработает ваш вызов и вернет ответ и управление. При этом все происходит в синхронном режиме, вы не сможете продолжить выполнение пока не получите ответа. Если происходит исключение на стороне сервера, то оно прилетит на клиента.
2. OneWay (или datagram) - данный способ отличается тем, что вызываемая метод контракта сторона (это может быть клиент, или сервер при дуплексной связи), не останавливается при вызове, а продолжает выполнение. Как если бы вызов практически сразу вернул результат. Иными словами мы в любом случае ожидаем доставки SOAP сообщения на противоположную сторону, но не ожидаем получения результата в ответ.
   Возможны ситуации, когда и при таком взаимодействии тоже произойдет блокировка потока на вызываемой стороне:
   
   • Когда при вызове, на сервере мы упираемся в какой то нагрузочный maxConcurrent* придел сервиса и наше сообщение с вызовом помещается в очередь на обслуживание. В этом случае мы будем ожидать пока вызов не встанет в обработку либо отвалимся по Timeout.
3. Duplex - это взаимодействие в обе стороны, когда клиент может вызывать методы сервера, а сервер, используя callback контракт, может вызывать методы клиента. Что бы это понять представьте чат, вы можете напечатать сообщение и отослать его на сервер, но что делать, если сообщение напишут вам? В этом случае сервер должен инициировать передачу на ваш компьютер. Как раз таки для этого он будет вызывать callback контракта, который задается отдельно, что бы уведомить вас.

Как реализуются данные схемы общения.

1. Request-reply. Данное поведение является "по умолчанию".
   
   

   [ServiceContract]
   internal interface IMyContract 

   {
       [OperationContract]
       void Method();
   }
   

2. OneWay. Для того, что бы метод контракта или callback контракта стал односторонним, достаточно указать IsOneWay = true.

   [ServiceContract]
   internal interface IMyContract
   {
       [OperationContract(IsOneWay = true)]
       void Method();
   }
   

3. Duplex. Для реализации используется свойство атрибута под названием CallbackContract.

   [ServiceContract(CallbackContract = typeof(ICallback))]
   internal interface IMyContract
   {
       [OperationContract]
       void Method1();
    
       [OperationContract(IsOneWay = true)]
       void MethodOneWay1();
   }
    
   [ServiceContract]
   internal interface ICallback
   {
       [OperationContract]
       void Method2();
    
       [OperationContract(IsOneWay = true)]
       void MethodOneWay2();
   }