Communicate between Applications

[Johnny E. Jensen]

Hello NG

I have two applications.

App1: Database application. Inserts/updates data to database.
App2: Notifier:
The notifier checks if a record has been created or modified, by loading the
table rows that has notify status 1 or 2. Thats easy. When the notifier
finds a record with 1 it brings up a window like in Outlook when new mail.

Now:
On the notifier form i want to have the ability to click on a button that
brings up App1 with the new data displayed.
And my question is: What to use to communicate between these two
applications in C#

Kind regards

Johnny E. Jensen

[Pavel Minaev]

On Aug 12, 11:08*pm, "Johnny E. Jensen" <[e-mail]:

Hello NG

I have two applications.

App1: Database application. Inserts/updates data to database.
App2: Notifier:
The notifier checks if a record has been created or modified, by loading the
table rows that has notify status 1 or 2. Thats easy. When the notifier
finds a record with 1 it brings up a window like in Outlook when new mail..

Now:
On the notifier form i want to have the ability to click on a button that
brings up App1 with the new data displayed.
And my question is: What to use to communicate between these two
applications in C#

You can use plain named pipes (see System.IO.Pipes), and serialize/
deserialize data manually. Or you can use .NET remoting (which can
also be set up to work over named pipes between two local processes).

[Andrei Varanovich [C# MVP]]

>I have two applications.

>>
App1: Database application. Inserts/updates data to database.
App2: Notifier:
The notifier checks if a record has been created or modified, by
loading the
table rows that has notify status 1 or 2. Thats easy. When the
notifier
finds a record with 1 it brings up a window like in Outlook when new
mail.
Now:
On the notifier form i want to have the ability to click on a button
that
brings up App1 with the new data displayed.
And my question is: What to use to communicate between these two
applications in C#

You can use plain named pipes (see System.IO.Pipes), and serialize/
deserialize data manually. Or you can use .NET remoting (which can
also be set up to work over named pipes between two local processes).

Why not to expose public properties and events in app1? Simple "observer"
desing pattern.

[Pavel Minaev]

On Aug 13, 10:02*am, Andrei Varanovich [C# MVP] <[e-mail]>
wrote:

I have two applications.

App1: Database application. Inserts/updates data to database.
App2: Notifier:
The notifier checks if a record has been created or modified, by
loading the
table rows that has notify status 1 or 2. Thats easy. When the
notifier
finds a record with 1 it brings up a window like in Outlook when new
mail.
Now:
On the notifier form i want to have the ability to click on a button
that
brings up App1 with the new data displayed.
And my question is: What to use to communicate between these two
applications in C#

You can use plain named pipes (see System.IO.Pipes), and serialize/
deserialize data manually. Or you can use .NET remoting (which can
also be set up to work over named pipes between two local processes).

Why not to expose public properties and events in app1? Simple "observer"
desing pattern.

He's talking about two different applications - that is, two different
processes - not a class library and an executable. You can't
subscribe to an event in a different process.

http://en.wikipedia.org/wiki/Inter-p..._communication

[Andrei Varanovich [C# MVP]]

He's talking about two different applications - that is, two different
processes - not a class library and an executable. You can't
subscribe to an event in a different process.

So you can't subscribe to MS Word or Excel event from your app?

[Duggi]

On Aug 13, 11:18*am, Pavel Minaev <[e-mail]:

On Aug 13, 10:02*am, Andrei Varanovich [C# MVP] <[e-mail]>
wrote:

>I have two applications.

>App1: Database application. Inserts/updates data to database.
>App2: Notifier:
>The notifier checks if a record has been created or modified, by
>loading the
>table rows that has notify status 1 or 2. Thats easy. When the
>notifier
>finds a record with 1 it brings up a window like in Outlook when new
>mail.
>Now:
>On the notifier form i want to have the ability to click on a button
>that
>brings up App1 with the new data displayed.
>And my question is: What to use to communicate between these two
>applications in C#
You can use plain named pipes (see System.IO.Pipes), and serialize/
deserialize data manually. Or you can use .NET remoting (which can
also be set up to work over named pipes between two local processes).

Why not to expose public properties and events in app1? Simple "observer"
desing pattern.

He's talking about two different applications - that is, two different
processes *- not a class library and an executable. You can't
subscribe to an event in a different process.

http://en.wikipedia.org/wiki/Inter-p...communication- Hide quoted text -

- Show quoted text -

I guess publish-subscribe pattern work fine here. There are standard
ways of implementing the observer pattern between the applications.
One of such implementation can use remoting.

[Duggi]

On Aug 13, 12:08*am, "Johnny E. Jensen" <[e-mail]:

Hello NG

I have two applications.

App1: Database application. Inserts/updates data to database.
App2: Notifier:
The notifier checks if a record has been created or modified, by loading the
table rows that has notify status 1 or 2. Thats easy. When the notifier
finds a record with 1 it brings up a window like in Outlook when new mail..

Now:
On the notifier form i want to have the ability to click on a button that
brings up App1 with the new data displayed.
And my question is: What to use to communicate between these two
applications in C#

Kind regards

Johnny E. Jensen

As I see this case can be solved using "observer" / publish-subscribe
pattern between the application. Check out the standard ways of
implementing the pattern. As a middle tire you can use number of
technologies like ".Net Remoting" or introduce a channel like MSMQ or
a media bus or can be achieved through windows service also. Let us
know more details of the requirement.

-Cnu.

[Pavel Minaev]

On Aug 13, 11:30*am, Andrei Varanovich [C# MVP] <[e-mail]>
wrote:

He's talking about two different applications - that is, two different
processes *- not a class library and an executable. You can't
subscribe to an event in a different process.

So you can't subscribe to MS Word or Excel event from your app?

You can, but it uses COM under the hood to do the remote invocation,
which does all the necessary marshalling (and probably ends up using
pipes, anyway). An apt .NET analog would be .NET remoting, as others
(including me) have already mentioned - but it still takes some effort
to implement, and it isn't quite seamless (even if close).

The main trick when using remoting when the client subscribes to event
and then sits there passively is to ensure proper lifetime management
of server objects.

Yes, for a server scenario, MSMQ is also a good option. But for a
relatively lightwent client app, Remoting over pipes is probably still
the easiest and the fastest.

[Andrei Varanovich [C# MVP]]

>>He's talking about two different applications - that is, two
different processes - not a class library and an executable. You
can't subscribe to an event in a different process.

So you can't subscribe to MS Word or Excel event from your app?

You can, but it uses COM under the hood to do the remote invocation,
which does all the necessary marshalling (and probably ends up using
pipes, anyway). An apt .NET analog would be .NET remoting, as others
(including me) have already mentioned - but it still takes some effort
to implement, and it isn't quite seamless (even if close).

The main trick when using remoting when the client subscribes to event
and then sits there passively is to ensure proper lifetime management
of server objects.

Yes, for a server scenario, MSMQ is also a good option. But for a
relatively lightwent client app, Remoting over pipes is probably still
the easiest and the fastest.

OK, let's stick on the remoting over pipes :-) In fact I was talking about
the pattern and you was talking about the transport to implement this pattern.

[Man T]

>>As I see this case can be solved using "observer" / publish-subscribe
pattern between the application. Check out the standard ways of
implementing the pattern. As a middle tire you can use number of
technologies like ".Net Remoting" or introduce a channel like MSMQ or
a media bus or can be achieved through windows service also. Let us
know more details of the requirement.

-Cnu.

As I am following this thread.
Any sample coding to do the .NET remoting for this scenario?