Lubomir wrote:
I have two processes and I need that one process will notify the other.
I could use the EventWaitHandle object and create an (named) event, but this
doesn't allow me to pass any parameters.
I think that:
delegate DelegateName;
event DelegateName MyEventObject;
object is not suitable for interprocess communication. Or am I wrong? If
yes, how could an object in one process subscribe to an event in another
process?
No, you're not wrong, because CLR processes don't share memory.
All I need it is to notify another process that something happend and pass
to him a simple parameter, like a short string.
Some candidates:
* WM_COPYDATA - requires using unsafe code, P/Invoke functions,
understanding Win32 API.
* TCP/IP - very simple but somewhat heavyweight, requires understanding
basics of .NET networking (not too difficult). Is portable (.NET not
required on other end) and scalable (apps could be on different
machines)
* .NET remoting - I've never used it, but I understand that it can do
this, and the underlying transport is flexible, but the other app
needs to be .NET too of course.
* Shared memory and event - this is using your named event, but also
adding the capability to share data, using some memory that is mapped
into both processes. Requires unsafe code, P/Invoke functions, more
intimate understanding of Win32 API.
* Other schemes:
- pipes (Win32 API etc. again),
- MSMQ (external service needs to be running; slightly awkward to
configure),
- drop file whose access is synchronized with named event and mutex,
like shared memory without the shared memory
If I were you, I'd go the remoting or TCP route. If you're not familiar
with either remoting or network programming, I think you'll learn more
useful info doing it with TCP than you would with remoting.
-- Barry
--
http://barrkel.blogspot.com/ 
