Hi, I'm working on developing a solution that requires me to display a
notification to the user in the form of a winform, much like the MSN
messenger popup or Norton 2004 popup. I am under the impression that
these apps consist of 2 pieces (or 3 if you consider an interface the 2
use) - a windows service that continually monitors for some event, and
the winform app that appears (and disappears) when the event is
received by the windows service. I think the winform app acts as the
remoting server, and the windows service acts as the client that calls
the server each time it wants the server to show the popup. I'm having
a tough time finding a working example of a windows form that acts as
remoting host and appears only when the windows service (remoting
client) asks it to. Can anyone provide me with a simple example to
show a form from a windows service using .NET remoting?
Thanks so much,
Chris

Since your application displays a UI, the first question I'd have is this:
does this service need to be running when no one is logged into the server
to receive its messages?

If the answer is no, then you probably don't want a service or remoting --
you just want an app that launches on startup for a particular user. You'd
write you app and then add and reference to it in the
HKCU\Software\Microsoft\Windows\CurrentVersion\Run registry key for each
user.

If it needs to always be running, then you need two parts:

1) A Windows Service that acts as a remoting server.
2) A client UI piece that launches with each login (i.e. in the same
registry key I mentioned above) and acts as a remoting client.

When the UI piece starts up, it connects to the service and registers for
whatever events the server may raise (e.g. when a certain file is modified).
It then displays the UI as appropriate.

The reason you shouldn't have the UI be the server is two fold:

1) How will the service know when the UI is running (i.e. when someone is
logged in)? Would it try to connect to the UI every time an event occurs?
2) Your app wouldn't work in a terminal services environment since only a
single UI could listen on the specified server port. This may not be a big
issue for you, but something to note.
3) You could never use a remote client to connect to your server to
subscribe for events. Again, this may not be a big deal currently, but it
could be a design consideration.

Hope that helps -
Ken


[quoted text, click to view]

Ken,

Thanks for the advice. I can't seem to get away from the idea that the
UI piece should be a server (singleton) and the service should be the
client. I would think you want the client (the service) to connect to
the server whenever the service decides that the UI needs to show up.
Why is my logic (according to everyone else it seems) backwards?
Thanks again.

Chris

Thank of the service as being your processing hub. The client UI is simply a
means of listening in on the activity of the server and perhaps issuing
instructions. You could imagine that you might have multiple clients (UIs)
that listen in. You could also imagine that your service might run for some
period of time without any clients.

Generally, in a client/server environment, the client is useless without the
services of the server, not vice versa. Plus, the server should be
long-lived with respect to the clients (which your would not be if you
reversed the roles).

Ken



[quoted text, click to view]