Взаимодействие моего приложения с моей службой , (на одном компе)

У меня будет слюжба (сервис) и приложение, которое должно служить интерфейсом этой службы. Служба в частности обращается к базе данных. Вопрос. Какие сейчас есть современные средства обмена данными между службой и приложением НА ОДНОМ КОМПЕ? Раньше я тупо использовал сокет на 127.0.0.1 для обмена. Может что поинтереснее есть? И чтобы данные легко было передавать и менять.

Средства сейчас остались теме же... Если очень уж хочется извратиться -- можешь Remouting поюзать...

Цитата Jupiter @ 01.04.08, 09:19

Может что поинтереснее есть?

1. System.Runtime.Remoting
2. Windows Communication Foundation

Цитата _hunter @ 01.04.08, 09:29

Если очень уж хочется извратиться

- почему извратиться? Отличное средство межпроцессного взаимодействия, + получаешь масштабируемость.

COM, Web Service, named pipe, File.Write + FileSystemWatcher, MSMQ...

Цитата J0ker @ 01.04.08, 19:54

COM, Web Service, named pipe, File.Write + FileSystemWatcher, MSMQ...

Но счет named pipe. Это ведь технология, основанная на WinAPI... Есть ли в .NET свежая оболочка для этой идеи?

Встречный вопрос, а чем не подходит Remoting?

Я не говорил, что он мне не подходит. Более того, скорее всего я на нем-то и остановлюсь. Но мне интересно про named pipes.

Цитата Jupiter @ 03.04.08, 14:51

named pipes.

кстати новая штука в .NET в 2.0 точно не было.

А если Remoting то там есть прикольный протокол как раз для локальной машины - IPC

Цитата Jupiter @ 03.04.08, 14:51

Но мне интересно про named pipes.

- если юзаешь 3.0, то для WCF если мне не изменяет память - один из видов байндинга

Цитата juice @ 03.04.08, 14:58

кстати новая штука в .NET в 2.0 точно не было.

Было зато в windows 3.1, так что условно новая

Цитата ANDLL @ 04.04.08, 06:55

Было зато в windows 3.1

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

Понимаю, что глупый вопрос, но все же... Вот я делаю ремоутинг, как советовал juice на канале IPC. Во всех примерах фигурируют три проекта: кроме клиента и сервера еще и сам класс, который будет создаваться удаленно. Где-то даже делают это не класс, а интерфейс. Мне не надо, чтобы была отдельная DLL для реализации класса. Хорошо, пусть это будет не класс, а интерфайс - какой-нибудь ICallableObject. Ну и где мне его описывать? Я делал в принципе как - описывал интерфайс одинаково дважды: в проекте сервера и в проекте клиента. И оно работало. Но не буду же я так делать всегда, хочется один раз его описать. То есть должен ли я описать интерфейс в одтельном файле .cs и включить этот файл в оба проетка, или держать описание интерфейса, скажем, в проете сервера, а в проекте клиента сделать референс?

Цитата Jupiter @ 07.04.08, 14:44

Ну и где мне его описывать?

Создается отдельный проект Сlass Library с твоим интерфейссом. Ты ссылаешься на него в проекте сервера (реализуешь интерфейс) и цепляешь его к клиенту, что бы иметь возможность обращаться к серверу. Иметь его как сs в проекте сервера не разумно, клиенту не нужна сборка с реализацией сервера. + к этому там где сборка с интерфейссом, можно объявлять собственные типы, которые могут пересекать границы домена между клиентом и сервером.

Сообщение отредактировано: juice - 07.04.08, 15:02

Цитата juice @ 07.04.08, 15:00

Создается отдельный проект Сlass Library с твоим интерфейссом ... + к этому там ... можно объявлять собственные типы, которые могут пересекать границы домена между клиентом и сервером.

И этот проект все-таки будет компилироваться в DLL? (извиняюсь за глупые вопросы, но я новичок в .net)

Цитата Jupiter @ 08.04.08, 10:52

этот проект все-таки будет компилироваться в DLL?

- да

Помучаю вас еще. Вот я сделал ремоутинг. Мой ipc-сервер реализован в службе Windows, клиент - обычное приложение (ехе-шник). Проблема в том, что все работает только когда служба-сервер запущена под пользовательской учетной записью (той же, под которой я рабтаю и запускаю клиентский ехе-шник). Стоит мне перевести службу под уч. запись Local Service (а именно так у меня и должно быть), в клиенте возникает исключение:
"Не удалось подключиться к IPC-порту: Отказано в доступе"
Вопрос: где задаются права на использование канала?
Спасибо.

Сделай Local System

Цитата PIL @ 16.04.08, 12:09

Сделай Local System

Все равно отказано в доступе

Перечислено,всё, что можно кроме стандартного МС подхода. Использовать надо нетовский ServiceController класс. и ,v частости, его метод OnCustomCommand.

Цитата MIF @ 16.04.08, 13:19

Использовать надо нетовский ServiceController класс

Спасибо. Я попробовал этот класс. Но к сожалению он больше подходит для запуска и останова служб. Плользовательское действие там предусмотрено, но это чрезвычайно скудный механизм. Ремоутинг рулит.

И вот еще что я заметил: ServiceController.CanStop выдает честно может или нет служба быть остановлена, но остановить ее не удается: метод ServiceController.Stop() дает все то же исключение: отказ доступа. Я пробовал не только мою службу, но и другие, которые там были. Результат один.

То есть и ремоутинг и ServiceController не имеют доступа. При этом ServiceController не может остановить/запустить службы НЕЗАВИСИМО от того, под какой уч. записью они работают, в то время как ремоутинг по крайней мере пашет при совпадении уч. записи службы и клиетна.

Задача остается прежней: наладить взаимодействие по ремоутингу (ipc) в случае когда служба запускается не под пользовательской уч. зап.

Кстати, забыл сказать, что пишу под Вистой. Может это важно...

Сообщение отредактировано: Jupiter - 16.04.08, 15:59

Цитата PIL @ 03.04.08, 18:00

- если юзаешь 3.0, то для WCF если мне не изменяет память - один из видов байндинга

и я что-то такое припоминаю.

Цитата Jupiter @ 16.04.08, 10:02

Помучаю вас еще.

Твои вопросы как бальзам на душу, жаль что помочь не могу. Самому интересно - поборол таки проблему?

Я пишу под Вистой. На сегодня я реализовал в своей системе два рекомендованных мне здесь механизма:
1. IPC-remoting для обмена данными между Службой и Приложением;
2. ServiceController для запуска и останова Службы из Приложения.

Оба механизма капризничают относительно прав доступа:
1. IPC-remoting работает только если Служба запущена под той же учетной записью, под которой работает Приложение;
2. ServiceController работает только если Приложение запущено "от имени администратора".

Вопросы:
1. Как настроить права Remoting, чтобы объяснить Службе, что ей нечего бояться и можно давать всем?
2. Как сделать так, чтобы при запуске Приложения не от имени администратора при попытке остановить/запустить Службу полозователю, как это принято в Висте, выдавалось бы предупреждение UAC, а не сразу отлуп?

Цитата

1. Как настроить права Remoting, чтобы объяснить Службе, что ей нечего бояться и можно давать всем?

Возможно мало прав при открытие точки, тогда нужно указать:

BinaryServerFormatterSinkProvider.TypeFilterLevel = TypeFilterLevel.Full; // полагаю, что у вас бинарный провайдер для IPC

Умные дяди скажут как это через app.config это сделать

Сообщение отредактировано: TerraGhost - 24.04.08, 15:11

Цитата

BinaryServerFormatterSinkProvider.TypeFilterLevel = TypeFilterLevel.Full;

Я сделал так. Теперь у меня вместо простенького

     configChannel = new IpcChannel("ConfigCommunicationIpcChannel");

стало вот такое:

     BinaryServerFormatterSinkProvider provider = new BinaryServerFormatterSinkProvider();
     provider.TypeFilterLevel = System.Runtime.Serialization.Formatters.TypeFilterLevel.Full;
 
     System.Collections.Hashtable props = new System.Collections.Hashtable();
     props["portName"] = "ConfigCommunicationIpcChannel";
 
     configChannel = new IpcChannel(props, null, provider);

Потенциальных возможностей больше, но работает по-прежнему только под пользовательской уч. зап.

Помогите, плиз! У меня возникла точно такая же проблема. как ее решить?????

Я хотел бы сообщить, как решились мои вопросы.

1. Для запуска и останова службы , работающей под уч записью Local Service, средствами ServiceController я применяю подход, описанный в
http://vstslive.wordpress.com/
А именно, в манифесте нужно прописать:
<requestedExecutionLevel level=”requireAdministrator” uiAccess=”false” />
В этом случае при старте программы выдается окно подтверждения на запуск от имени администратора. Конечно, лучще было бы выдавать запрос не при старте программы, а непосредственно перед выполнением действия по старту/остановке службы. Но это уже и так огромный прогресс.

2. Проблемы с Remouting решились после отказа от Remouting в пользу кошачей технологии (с неудобопроизносимым названием CWF).