IPC в .Net может быть достигнуто с помощью:

WCF

с использованием именованных каналов требуется .Net 3.0 и выше.

Пример кода

• Класс WCF NetNamedPipeBinding может использоваться для межпроцессного взаимодействия на одном компьютере. Документация MSDN для этого класса включает пример кода, охватывающий этот сценарий http://msdn.microsoft.com/en-us/library/system.servicemodel.netnamedpipebinding.aspx

Удаленное взаимодействие

Исходный фреймворк IPC, выпущенный с .Net 1.0. Я считаю, что удаленное взаимодействие больше не активно развивается, и вам рекомендуется использовать вместо этого WCF.

Пример кода

Межпроцессное взаимодействие через удаленное взаимодействие - использует канал TCP

Ресурсы

• GenuineChannels, продавайте набор инструментов для удаленного взаимодействия, который включает канал общей памяти. http://www.genuinechannels.com/Index.aspx
• Advanced .NET Remoting, Second Edition

Win32 RPC с использованием csharptest-net RpcLibrary

Недавно я наткнулся на проект, который обернул библиотеку Win32 RPC и создал библиотеку классов .net, которую можно использовать для локального и удаленного RPC.

Домашняя страница проекта: http://csharptest.net/projects/rpclibrary/

Ссылки MSDN:

• Как работает rpc: http://technet.microsoft.com/en-us/library/cc738291(v=ws.10).aspx
• Функции RPC: http://msdn.microsoft.com/en-us/library/aa378623(v=VS.85).aspx

Также есть клиент rpc буферов протокола Google, который работает поверх библиотеки: https://code.google.com/p/protobuf-csharp-rpc/

WM_COPYDATA

Для полноты картины также можно использовать метод WIN32 с сообщением WM_COPYDATA. Я использовал этот метод раньше в .Net 1.1 для создания приложения с одним экземпляром, открывающего несколько файлов из проводника Windows.

Ресурсы

• MSDN - WM_COPYDATA
• Пример кода
• декларация PInvoke.net

Розетки

Использование собственного протокола (сложнее)

Только для локальных пользователей мы добились успеха с использованием именованных каналов. Избегает накладных расходов TCP и в значительной степени (по крайней мере, для .NET) настолько эффективен, насколько вы можете получить, а также имеет приличный API для работы.

Поскольку вы ограничены .Net 2.0, WCF, возможно, не подходит. Вы можете использовать удаленное взаимодействие .Net с общей памятью в качестве основного механизма связи между доменами приложений на одном компьютере. Используя этот подход, вы можете легко разместить свои процессы на разных машинах и заменить протокол общей памяти сетевым протоколом.

Стандартный метод связи со службой Windows - использование кодов управления службами. Службы Windows могут получать коды от 0 до 255. 0-127 зарезервированы для системы. От 128 до 255 можно использовать для пользовательских команд.

Если вам нужно отправить сложные объекты в службу, используйте базу данных, xml, файл, tcp, http и т. Д. Кроме того, для отправки команд управления, таких как перезагрузка конфигурации, элементов процесса и т. Д., Следует использовать эти управляющие коды.

Доступны дополнительные функции, такие как запросы к службе. См. Служебную документацию Windows и api.

http://arcanecode.com/2007/05/30/windows-services-in-c-sending-commands-to-your-windows-service-part-7/

Лучше всего использовать WCF. Вы сможете создать узел службы в службе Windows и предоставить четко определенный интерфейс, который может использовать приложение с графическим интерфейсом. WCF позволит вам общаться через именованные каналы, если вы выберете, или вы можете выбрать любой другой протокол связи, такой как TCP, HTTP и т. Д. Используя WCF, вы получаете отличную поддержку инструментов и много доступной информации.

Я хотел бы добавить к этому обсуждению. Пожалуйста, упрекните меня, если это выход - но нельзя ли использовать семафор (или несколько семафоров) для рудиментарного взаимодействия?