Межпроцессная связь для Windows на С# (.NET 2.0)
Мне никогда не приходилось делать IPC в Windows раньше. В настоящее время я разрабатываю пару программ, стандартное приложение GUI/CLI и службу Windows. Приложение должно сообщить службе, что делать. Итак, предполагая, что связь является только локальной, какой был бы лучший способ связи для этих двух процессов?
Где лучше всего определяется как более надежный и менее подверженный ошибкам, а не самый эффективный или простой код.
Примеры кода будут очень желанными, но не требуются: -)
Примечание. Я спрашиваю, что использовать, стандартный TCP-сокет, именованные каналы или какие-либо другие средства связи.
Спасибо!
Ответы
Ответ 1
IPC в .Net может быть достигнуто с помощью:
WCF
с использованием именованных каналов требуется .Net 3.0 и выше.
Пример кода
Remoting
Оригинальная структура IPC, выпущенная с .Net 1.0. Я считаю, что удаленный доступ уже не активно развивается, и вам предлагается использовать WCF вместо
Пример кода
Inter-process communication via Remoting - использует tcp-канал
Ресурсы
Win32 RPC с использованием csharptest-net RpcLibrary
Недавно я столкнулся с проектом, который обернул библиотеку RPC Win32 и создал библиотеку классов .net, которая может использоваться для локального и удаленного RPC
Домашняя страница проекта: http://csharptest.net/projects/rpclibrary/
Ссылки MSDN:
Также есть клиент rpc-буферов протокола google, который работает поверх библиотеки: https://code.google.com/p/protobuf-csharp-rpc/
WM_COPYDATA
Для полноты также можно использовать метод WIN32 с сообщением WM_COPYDATA. Я использовал этот метод раньше в .Net 1.1, чтобы создать одно приложение-экземпляр, открывающее несколько файлов из обозревателя Windows.
Ресурсы
Розетки
Использование настраиваемого протокола (сложнее)
Ответ 2
Только для локальных, мы успешно использовали Именованные каналы. Избегайте накладных расходов на TCP и в значительной степени (по крайней мере для .NET) настолько эффективны, насколько вы можете получить, а также иметь достойный API для работы.
Ответ 3
Поскольку вы ограничены .NET 2.0 WCF, возможно, не вариант. Вы можете использовать удаленную сеть .Net с разделяемой памятью как основной механизм связи между доменами приложений на одной машине. Используя этот подход, вы можете легко разместить свои процессы на разных машинах и заменить протокол разделяемой памяти на сетевой протокол.
Ответ 4
Стандартным методом связи с службой Windows является использование кодов управления услугами. Службы Windows могут получать коды от 0 до 255. 0-127 зарезервировано для системы. От 128 до 255 могут использоваться для пользовательских команд.
Если вам нужно отправить сложные объекты в базу данных службы, xml, file, tcp, http и т.д. Помимо этого для отправки управляющих команд, таких как конфигурация перезагрузки, элементы процесса и т.д., эти управляющие коды должны использоваться.
Существуют дополнительные функциональные возможности, такие как запрос службы. См. Документацию по обслуживанию Windows и api.
http://arcanecode.com/2007/05/30/windows-services-in-c-sending-commands-to-your-windows-service-part-7/
Ответ 5
Лучше всего использовать WCF. Вы сможете создать хост службы в службе Windows и выставить хорошо определенный интерфейс, который может использовать приложение GUI. WCF позволит вам общаться по именованным каналам, если вы выберете, или вы можете выбрать любой другой протокол связи, такой как TCP, HTTP и т.д. Используя WCF, вы получаете отличную поддержку инструмента и много доступной информации.
Ответ 6
Я бы хотел добавить к этому обсуждению. Пожалуйста, упрекните меня, если это путь - но не мог ли семафор (или несколько семафоров) использоваться для рудиментарного общения?