Если есть 2 программы, написанные на С#, как от одной из них послать сообщение другой?
Можно через вызов С++ функций, но разве нет у .Net своего способа?

Вообще, какой самый простой способ сделать так, чтобы у второй программы сработало событие, сгенерированное первой программой?

Здравствуйте, DowJones, Вы писали:

DJ>Если есть 2 программы, написанные на С#, как от одной из них послать сообщение другой?
DJ>Можно через вызов С++ функций, но разве нет у .Net своего способа?

DJ>Вообще, какой самый простой способ сделать так, чтобы у второй программы сработало событие, сгенерированное первой программой?
здесь

Здравствуйте, DowJones, Вы писали:

DJ>Вообще, какой самый простой способ сделать так, чтобы у второй программы сработало событие, сгенерированное первой программой?

Попробуйте WCF Self-hosted service.

В более сложных случаях используют MOM

Также, иногда, данные передают через общее хранилище. Создают табличку Messages в БД.
Одно приложение пишет, другое читает. Но тут очень часто можно "напороться" на "багодром".
Так что советую Вам попробывать 1-й вариант.

Здравствуйте, DowJones, Вы писали:

DJ>Если есть 2 программы, написанные на С#, как от одной из них послать сообщение другой?
DJ>Можно через вызов С++ функций, но разве нет у .Net своего способа?

DJ>Вообще, какой самый простой способ сделать так, чтобы у второй программы сработало событие, сгенерированное первой программой?

Что имеется в виду под "событие"?

В Виндоуз один из самых "дешёвых" способов — именованные каналы aka pipes, поддержка которых появилась в третьем с половиной фреймворке: How to: Use Named Pipes to Communicate Between Processes over a Network.

Здравствуйте, DowJones, Вы писали:

То, что Вы хотите, называется Interprocess Communications, IPC. Погуглите, почитайте MSDN, способов существует много.

Здравствуйте, SаNNy, Вы писали:

DJ>>Вообще, какой самый простой способ сделать так, чтобы у второй программы сработало событие, сгенерированное первой программой?
SNN>здесь

Нет, ремотинг следует применять только там, где без него не обойтись, а именно для обеспечения взяимодействия доменов [внутри одного процесса] — для всего остального взаимодействия есть более специализированные и лучше предназначенные технологии.

Приветствую. Аналогичная проблема (выбор механизма IPC).

Чуть ранее остановился на pipe. Два дня убил на отладку: 1) одной дву-направленной именованной "трубы"; 2) двух встречно одно-направленных именованных; 3) двух встречно направленных анонимных pipe'а.

Все в нужном режиме не заработало, поскольку, как оказалось, с самой первой платформы и до версии 3.5 существуют минимум два бага с методом StriamReader.Peek():

1) метод Peek() блокирует поток при отсутствии в канале данных для чтения, а так же в каких-то других (до конца не разобрался) случаях. Подробней — http://connect.microsoft.com/VisualStudio/feedback/details/96484/streamreader-peek-can-block

2) в какие-то моменты метод Peek() продолжает возвращать значение -1 даже если в pipe есть данные. Не особо разбирался, но похоже на то, что если в pipe записано два и более сообщения, то метод ReadLine возвращает первое из них, при этом читая ВСЕ данные из pipe, при этом второе сообщение уже не в трубе (видимо во внутреннем буфере StriamReader), а Peek при этом "видит" (хотя и является методом StriamReader, а не pipe'ов), что в трубе больше ничего нет и читать нечего.. хотя второе сообщение все еще "висит" непрочитанным. Чтобы было понятней:

Immediate Window (во время приоставновки кода отладчиком в момент, когда в pipe записано два сообщения и уже прочитано одно из них, а второе все еще ждет своего "прочтения"):
? mobjPipeStreamReader.Peek
-1 (т.е. Peek говорит о том, что читать пока что нечего)
? mobjPipeStreamReader.ReadLine
"SecondTestMessage" (т.е. не смотря на то, что читать нечего, ReadLine прочитал очередное сообщение!!)

К чему я все это.. к тому, что когда меня весь инет агитировал за использование Pipe'ов (.NET), то все как один, приводя простейшие примеры, молчали о этих багах... и я потерял два дня, нервы, веру в свои ровные руки и т.п.

P.S. Чо делать-то? Remoting для моего случая избыточен... workaround'ов для описанных случаев в сети нет и сам не нашел (кроме как создавать отдельный поток, но в моем случае таких потоков будет тогда ну ооочень много)... Посоветуйте куда смотреть для создания LocalHost-IPC между "Сервером" и "неконтроллируемым количеством клиентов", при том, что сообщения будут короткими (десяток-два символов) и пакетными (несколько десятков в секунду, после чего тишина на десятки секунд)...
Или уже добивать вариант с pipe'ами и для каждого канала с двух сторон делать по отдельному процессу, который и будет не трогая Peek вообще (от греха подальше) тупо сидеть и ждать, когда в трубу что-нибудь запишут.. но это будет столько потоков.. что.. даже не знаю..

Чо делать?

P.S.2. Извините за много букв.. я просто

Перечитал... конечно не процессу, а потоку...:

А>Или уже добивать вариант с pipe'ами и для каждого канала с двух сторон делать по отдельному >>>ПОТОКУ<<<, который и будет не трогая Peek вообще (от греха подальше) тупо сидеть и ждать, когда в трубу что-нибудь запишут.. но это будет столько потоков.. что.. даже не знаю..

Здравствуйте, Аноним, Вы писали:

А>К чему я все это.. к тому, что когда меня весь инет агитировал за использование Pipe'ов (.NET), то все как один, приводя простейшие примеры, молчали о этих багах... и я потерял два дня, нервы, веру в свои ровные руки и т.п.

Два дня… Это мелочи для исследования/разбирания и ого-го для тренировки. Бывали случаи, когда годами что-то разработывалось, но так и не выпускалось, ибо какие-то мелочи в выбранной технологии не позволяли получать от неё, технологии, того, что хотелось. Записывайте эти дни себе в опыт большим плюсом.

Часто попадаются в BCL/FCL куски, написанные неправильными индусами

А>P.S. Чо делать-то? Remoting для моего случая избыточен...

Remoting, скорее, будет недостаточен, ибо призван решать более узкоспециализированные задачи.

А>workaround'ов для описанных случаев в сети нет и сам не нашел (кроме как создавать отдельный поток, но в моем случае таких потоков будет тогда ну ооочень много)... Посоветуйте куда смотреть для создания LocalHost-IPC между "Сервером" и "неконтроллируемым количеством клиентов", при том, что сообщения будут короткими (десяток-два символов) и пакетными (несколько десятков в секунду, после чего тишина на десятки секунд)...

Возьмите не ремотинг, а WCF. Почему он будет избыточен? Зато, как флагманская технология, самая защищённая от случайных траблов (но могут быть не случайные ).

А>P.S. Чо делать-то? Remoting для моего случая избыточен... workaround'ов для описанных случаев в сети нет и сам не нашел (кроме как создавать отдельный поток, но в моем случае таких потоков будет тогда ну ооочень много)... Посоветуйте куда смотреть для создания LocalHost-IPC между "Сервером" и "неконтроллируемым количеством клиентов", при том, что сообщения будут короткими (десяток-два символов) и пакетными (несколько десятков в секунду, после чего тишина на десятки секунд)...
А>Или уже добивать вариант с pipe'ами и для каждого канала с двух сторон делать по отдельному процессу, который и будет не трогая Peek вообще (от греха подальше) тупо сидеть и ждать, когда в трубу что-нибудь запишут.. но это будет столько потоков.. что.. даже не знаю..

А>Чо делать?

MSMQ ?

Здравствуйте, Аноним, Вы писали:

А>Все в нужном режиме не заработало, поскольку, как оказалось, с самой первой платформы и до версии 3.5 существуют минимум два бага с методом StriamReader.Peek():
Вместо StreamReader/Writer используем BinaryReader/Writer

Недавно разгребался: http://www.rsdn.ru/forum/dotnet/3981769.aspx

Автор: Sinix
Дата: 02.10.10

.

Анонимные пайпы подойдут, только если второй процесс — дочерний первого.
WCF ради IPC заводить не советую — NamedPipeBinding там дурной

Автор: Sinix
Дата: 05.10.10

.

Ремотинг — забыть как страшный сон
http://www.rsdn.ru/forum/dotnet/3389286.flat.aspx

Автор: Sinix
Дата: 14.05.09

http://www.rsdn.ru/forum/dotnet/3390879.flat.aspx

Автор: Sinix
Дата: 15.05.09

Главная проблема у вас будет не с "как передать данные", а с "как сделать, чтоб никто сторонний не передал/прочитал". В рамках разумного, конечно

>QrystaL
>MSMQ ?
Там, вроде, много избыточного функционала (гарантированная доставка сообщений даже при нахождении в оффлайне одного из процессов, что мне не нужно) и еще вроде какой-то сервис поднимать нужно.. хотя я не работал с этим.. тоже посмотрю, спасибо)

>_FRED_
>Два дня… Это мелочи для исследования/разбирания и ого-го для тренировки.
Да, но так хочется, чтобы сразу все "plug&play"..

>Возьмите не ремотинг, а WCF.
Это что-то совсем новое для меня.. мм.. я для "души" программлю, поэтому не получается оперативно отслеживать новые технологии, при том что старые (pipe'ы вне .NET) работали как часы всегда.. Посмотрю что это, спасибо!

>Sinix
эээм.... кажется это то, что мне нужно прочитать и понять от и до... ушел читать, спасибо за инфо и советы)

P.S. Пошел читать и думать... Огромное спасибо за оперативные и информативные ответы!! Появилось направление "куда теперь копать")

эт я, Аноним 806..

>Sinix
>Главная проблема у вас будет не с "как передать данные", а с "как сделать, чтоб никто сторонний не передал/прочитал"
Понял, подумаю над возможными последствиями для проги...

>Вместо StreamReader/Writer используем BinaryReader/Writer
Не катит ибо мне нужно читать "трубу" асинхронно (или хотябы эмулировать асинхронность — через Peek проверять, можно ли уже читать данные и если можно, то только тогда читать, чтобы поток не блокировался), а BinaryWriter/Reader при работе с трубами штатным поведением Peek() является возврат "-1" (т.к. "...pipe не поддерживает метода Seek") вне зависимости от наличия даных для чтения...

В итоге... исходя из:
1) это всего лишь первая итерация (наброски) в написании проги;
2) жутко хочу продолжить работать над логикой проги, а не над тестированием платформы и своих нервов ;
3) отсутствия методов асинхронного чтения как у BinaryReader, так и у StringReader;
4) невозможности использования Peek() для эмуляции асинхронного чтения (у BinaryReader — это фича, у StringReader — баг);
5) наличия неплохих знаний о непосредственно пайпах (в целом, не реализация в .NET);
...сделал все непосредственно на уровне PipeServerStream/PipeClientStream, без всяких дополнительных оберток, используя асинхронные BeginRead()....

Еще раз сорри за много букв, но, возможно, какому-нибудь новичку типа меня это сэкономит время..

P.S. спасибо за инфо о WCF — вроде мощная штука, но не в этот раз)

Спасибо!)

Спасибо за ответы, но я, честно говоря, предполагал, что C# повзоляет это делать более просто.
Я себе это представлял как-то так
Первая программа выставляет событие (по аналогии с CreateEvent в С++).
А вторая это событие отслеживает в основном потоке программы (то есть без создания дополнительных потоков) (то есть в ней просто создается обработчик события)

Здравствуйте, DowJones, Вы писали:

DJ>Первая программа выставляет событие (по аналогии с CreateEvent в С++).
DJ>А вторая это событие отслеживает в основном потоке программы (то есть без создания дополнительных потоков) (то есть в ней просто создается обработчик события)

Поток не может выполнять два действия одновременно, а чтобы вызвался обработчик события, то его кто-то должен вызвать . В принципе, в WinApi, как Вам, возможно, известно, есть функция MsgWaitForMultipleObjects, позволяющая совместить ожидание сообщений и нескольких объектов ядра, однако и там обработка результата ожидания может быть только строго последовательная, если у Вас этим занимается только один поток.

Однако если Вам нужно просто дождаться события без передачи параметров, то и в NET Вы можете воспользоваться тем-же именованным Event'ом, и ждать его либо отдельным потоком, либо импортировать ту-же MsgWaitForMultipleObjects.

Здравствуйте, Аноним, Вы писали:

А>В итоге... исходя из:
Ну да, только собрался предложить такой вариант

Здравствуйте, DowJones, Вы писали:

DJ>Если есть 2 программы, написанные на С#, как от одной из них послать сообщение другой?

Да взять и послать! SendMessage. Сообщение называется WM_COPYDATA и позволяет передать любую информацию. Единственное — придется зафиксировать блок перед передачей. Пишется в несколько строчек на обеих сторонах.

Здравствуйте, Jolly Roger, Вы писали:

JR>Здравствуйте, DowJones, Вы писали:

DJ>>Первая программа выставляет событие (по аналогии с CreateEvent в С++).
DJ>>А вторая это событие отслеживает в основном потоке программы (то есть без создания дополнительных потоков) (то есть в ней просто создается обработчик события)

JR>Поток не может выполнять два действия одновременно, а чтобы вызвался обработчик события, то его кто-то должен вызвать . В принципе, в WinApi, как Вам, возможно, известно, есть функция MsgWaitForMultipleObjects, позволяющая совместить ожидание сообщений и нескольких объектов ядра, однако и там обработка результата ожидания может быть только строго последовательная, если у Вас этим занимается только один поток.

JR>Однако если Вам нужно просто дождаться события без передачи параметров, то и в NET Вы можете воспользоваться тем-же именованным Event'ом, и ждать его либо отдельным потоком, либо импортировать ту-же MsgWaitForMultipleObjects.

Ну смотрите, программа представляет из себя поток, который крутится, ловит сообщения и потом вызывает для каждого свой обработчик. То есть например нажатие мышью и тд.
Так вот, я думал, есть возможность включить в этот основной поток возможность отлавливания и каких-то своих сообщений.
Или .Net как-то по другому работает?

Здравствуйте, DowJones, Вы писали:

DJ>Ну смотрите, программа представляет из себя поток, который крутится, ловит сообщения и потом вызывает для каждого свой обработчик. То есть например нажатие мышью и тд.
DJ>Так вот, я думал, есть возможность включить в этот основной поток возможность отлавливания и каких-то своих сообщений.
DJ>Или .Net как-то по другому работает?

Почему-же, ровно так-же. Но если Вас устраивает просто посылка сообщения, то тогда не ясно из-за чего весь сыр-бор Отправить сообщение — импортировать SendMessage, PostMessage or PostThreadMessage, принять — например, Application.AddMessageFilter Или что? Попробуйте ещё раз сформулировать вопрос, что именно вызывает затруднения?

Здравствуйте, DowJones, Вы писали:

Правильно заданный вопрос — это половина ответа.
Ваш же вопрос сформулирован так, что вы можете получить верный ответ на него только случайно.
Сейчас я продемонстрирую это (причем не для вас лично, а для всех кто плохо формулирует вопросы).

DJ>Если есть 2 программы, написанные на С#, как от одной из них послать сообщение другой?

Программы (не важно на чем они написаны) могут быть написаны по разному и работать в разных условиях. Так ваши программы могут быть GUI-приложениями написанными с помощью WinForms, могут быть GUI-приложениями написанными с WPF, могут быть GUI-приложениями написанными с GTK+ (и работающими под Mono+Линукс), могут быть консольными приложениями, а могут быть вообще сервисами или демонами.

Для каждого вида приложения можно предложить разные случаи передачи сообщений.

Что вы понимаете под "сообщением" тоже не понятно. Это может быть оконное сообщение Windows, а может сообщение посланное через сеть через специальный сервис.

Поймите, тут нет телепатов. Описывайте свою задачу и условия при которых она должна выполняться.

DJ>Можно через вызов С++ функций, но разве нет у .Net своего способа?

Опять же, что значит через "вызов С++ функций"? Да вы раком встанете чтобы вызвать функцию именно С++ (т.е. неуправляемого С++) это на С++-то сделать очень не просто, а уж на дотнете вообще граничит с шаманством.

Возможно что под "вызов С++ функций" имелось ввиду функция Win API, а возможно вызов некой С (подчеркиваю, Си, а не С++) библиотеки.

DJ>Вообще, какой самый простой способ сделать так, чтобы у второй программы сработало событие, сгенерированное первой программой?

О, к сообщению прибавилось еще и событие. А под этим словом что понимается? Событие как примитив ОС? Или событие объекта в C#?