создание долгоживущего сервера для других приложений на windows

Question

Я изучил COM-серверы и службы Windows, но я не уверен, что лучше всего подходит для моих целей или как это сделать. То, что я хочу, это то, что можно запускать и запускать в течение неопределенного времени, которое содержит объект, так что другие процессы или приложения получают ссылки на этот объект (или делают запросы к серверу) для изменения или запроса его состояния.

Сервер - это, по сути, приложение, которое обрабатывает команды для устройства через последовательный порт и поддерживает внутреннее состояние устройства.

У меня есть функция связи и сохранения устройства, написанная на C # прямо сейчас, и она может быть создана и запущена для каждого отдельного процесса, но, очевидно, я хочу, чтобы она была создана один раз и запущена независимо от других процессов.

COM-уроки, которые я прочитал, только смутили меня, так как я не был полностью уверен, что это то, чего я хотел, и я надеялся, что для этого будет больше .Net.

Любая помощь будет безмерно признательна!

Answer 1

это похоже на естественное соответствие для службы Windows. Я должен сказать, что я не программист .net, но я понимаю, что вы можете создавать сервисы с помощью .net. если вы знаете, что можете манипулировать последовательным портом с помощью .net, все будет хорошо.

-don

Answer 2

Вы, кажется, спрашиваете о двух вещах -

1. способ размещения долго работающего, постоянного приложения в Windows, которое будет переключаться с тем или иным устройством через последовательный порт.
2. способ связи с этим приложением из других приложений.

Служба Windows - хорошее решение для первого. Служба Windows выступает в качестве хоста приложения для вашей пользовательской логики. Это дает вам возможность запускать / останавливать и облегчает мониторинг и конфигурирование с помощью общего интерфейса и API. Сервисы Windows легко создавать на C #. Запускать и останавливать службы Windows легко из командной строки, из приложения, из инструмента с графическим интерфейсом.

Думайте о WCF как о главном коммуникационном интерфейсе. WCF может использоваться для создания внешнего интерфейса, предоставляемого службой Windows. Если вы хотите подключиться к приложению (службе) из клиентов .NET или HTTP (REST или SOAP), то WCF будет работать для вас.

COM .... Беспорядок, с которым вы сталкиваетесь в связи с использованием COM, связан с тем, что COM связывает механизм интерфейса (IDispatch, IUnknown и т. Д.) С моделью хостинга + жизненного цикла (локальные серверы, серверы Inproc, Удаленные серверы, автоматический запуск по запросу и т. Д.). Хостинг и жизненный цикл в COM работали, но всегда были довольно тонкими. Трудно понять, какие услуги были, и как долго. Трудно начать и остановить по требованию.

COM, в этой ситуации, как и WCF, в первую очередь представляет интерес как коммуникационный интерфейс. Если вы хотите использовать компонентный интерфейс для подключения к службе, COM может быть хорошим дополнением к службе Windows для хостинга.

COM и WCF (REST или SOAP) не являются взаимоисключающими, и на самом деле многие приложения предоставляют несколько интерфейсов. Вы можете выбрать сделать одно или другое, или оба. Там нет неправильного ответа, это зависит от ваших требований.

Если бы я делал это, я бы использовал службу Windows, а также я бы выставил интерфейс COM из этой службы, , как описано здесь . О жизненном цикле и хостинге заботится служба Windows. Сервис доступен через COM, то есть практически через любой язык программирования или скриптовую среду. Javascript, VB6, Excel или OFfice, Python, Perl и т. Д.

Я бы также подумал о предоставлении интерфейса WCF из сервиса. Это также позволит подключиться любому клиенту REST. Думайте о WCF как о беспроводном телефоне, а о COM - как о стационарном. Иногда хочется только одного. Иногда вы хотите оба.

Answer 3

Ваши требования немного противоречивы - если сервер должен работать бесконечно, независимо от того, есть клиенты для обслуживания или нет, и процесс должен быть общим для всех клиентов, независимо от сеанса, в котором они работают, Windows Услуги - это путь.

Если вы хотите, чтобы сервер работал только при наличии клиентов, и, возможно, (или нет), чтобы эти клиенты совместно использовали один и тот же процесс сервера, можно использовать серверы COM Out Of Process.

В случае COM вам необходимо использовать DCOM для связи с процессом сервера. В случае сервисов вы можете использовать DCOM, именованные каналы, RPC или какой-либо другой механизм IPC.

Если вы хотите закодировать сервер в C #, однако, DCOM кажется немного странным выбором - возможно создать серверы DCOM в C #, но это действительно неудобно. Как отметил Кевин, WCF / WAS / Remoting может оказаться более легким выбором. Но имейте в виду, что такое решение почти наверняка будет иметь значительно более высокие накладные расходы в.р. потребление памяти, чем собственный сервер COM или службы. Если это программное обеспечение будет установлено на клиентских компьютерах, я бы предпочел собственное решение.

Answer 4

Я хотел бы создать для этого службу Windows Communication Foundation (WCF) и предоставить ее с одной из множества доступных привязок. Вы можете выставить его через HTTP / SOAP, HTTP / REST, TCP / Binary, MSMQ и т. Д. Из одной и той же службы. Если у вас Windows 2008, вы можете активировать ее через службу активации Windows (WAS). Если у вас есть другая ОС Windows, вы должны написать службу Windows, которую можно зарегистрировать в диспетчере управления службами (SCM). Здесь много вариантов, но я бы определенно склонялся к использованию WCF для создания вашего сервиса. Там так много «сантехники», что WCF позаботится о вас. Не нужно изобретать все это. Надеюсь, это поможет.