Tom,
Your service needs to expose an interface via .Net remoting. This involves
architecting your service using two projects: a main program (either
WinForms or console) and a class library. The class library must contain a
public class that inherits from MarshalByRefObj ect. You need to add code to
the main program to register a TCP channel with the .Net remoting
architecture, and register the public class as a well-known singleton.
You also need to create a WinForms app that can be run by logged-in users.
This app communicates with the user via a menu attached to a
NotificationIco n object. This app communicates with your service via the
remoted class exposed by the service (above). You would set up this app so
that it runs automagically when the user logs in.
FYI, if your client app just wants to call methods on the service's remoted
interface then the client doesn't need to register a TCP channel; it just
needs to call Activator.GetOb ject to get a reference to the remoted
singleton. However, if you want to handle events from the remoted object
then you need to jump through some significant, not-very-well-documented
hoops:
1. Your client needs to register a TCP channel (port 0, which allocates an
unused port, will suffice). This is because the event callback looks like a
method invocation to the remoting architecture; thus, the singleton needs to
be able to call a method on the client, so the client needs a TCP channel to
receive the method invocation request.
2. The singleton needs to be able to access the client's metadata in order
to resolve the reference to the client's event handler. The easiest way to
accomplish this is to set up your build and deployment environments so that
the client's executable resides in the same folder as the singleton's dll.
A more elegant solution that doesn't require the singleton to know about
each of its clients involves declaring an interface in the singleton's
project that contains the event handlers, implementing the interface in each
client, and providing a method on the singleton that hooks up the events on
behalf of the client.
"SimpTheChi mp" <Si**********@d iscussions.micr osoft.com> wrote in message
news:CA******** *************** ***********@mic rosoft.com...
Hey all! Thanks for the info.... one question still remains, though, as I
looked all this over: I seen how I can communicate things INTO the service
(by using the custom command thingy) but how do I get custom info OUT of
the service (other than the base things). Maybe, for instance, I want my UI to
be able to query the service to see exactly what it is doing at this time
(i.e., if it is processing a record - which record? Or if it is processing a
file - which file?) Since, from what I understand, a service doesn't support
public interfaces, how would one go about getting this kind of custom info from a
service?
Tom (Chimp)
