raising events from a windows service

  • Thread starter Thread starter Trevor Braun
  • Start date Start date
T

Trevor Braun

I have a windows service that generates events when it finds certain
database information. That is, the service runs, and on a timer event, it
checks a few database tables for new records. If the new records have been
created, it generates the NewRecord event.

I would like to have a client application subscribe to the events generated
by the windows service, but when I attempt to use the service as a reference
in my VS.NET project, I get an error that says I can only reference DLL's.

Can anyone recommend a way for me to "accomplish my mission"?

Thanks,
Trevor Braun
 
I believe that with .Net you are going to have to use remoting to do this.
My question for you is:

If both these programs are running on the same system, why not have the
client program check for the new records and handle them internallly?

Chris
 
Thanks for the thoughts.
I didn't mean to give the impression that the client application would be
running on the same machine, however at present (during development) that
would be the case.
I understand that remoting will be required for the eventual deployment, but
for building and testing the windows service, I just wanted a simple client
application that could monitor the events being raised by the service. How
will remoting affect this? BTW, I haven't used .NET remoting before.

Trevor
 
Trevor said:
I have a windows service that generates events when it finds certain
database information. That is, the service runs, and on a timer
event, it checks a few database tables for new records. If the new
records have been created, it generates the NewRecord event.

I would like to have a client application subscribe to the events
Click to expand...

Stop there. Client *application*. Windows *service*. You have two processes.
generated by the windows service, but when I attempt to use the
service as a reference in my VS.NET project, I get an error that says
I can only reference DLL's.
Click to expand...

That's because the memory address for your event handler is only valid in
the current process. Your service is another process.
Can anyone recommend a way for me to "accomplish my mission"?
Click to expand...

You have to use .NET remoting. .NET remoting is used to marshal calls
between two AppDomains. Those AppDomains could be in the same process, could
be in two different processes on the same machine (your situation) or in two
different processes on two different machines.

Note that if the service is running as LOCALSYSTEM it won't be able to raise
an even to a client on another machine because LOCALSYSTEM does not network
privileges.

It depends on what sort of data you pass in the event, if its simple data
then I would favour use a lightweight solution like a socket to pass the
data to the client. (If you have some database rowobject, you just need to
serialize the object, send it through the socket and deserialize it on the
client side.)

Richard
 
Thanks for the terrific explanation. I'll do some more research on the
remoting before I continue.

Trevor
 
I've looked at the remoting stuff, and gotten a sample (remote DLL) working,
but still not across applications.

I'm lost as to how I can have the client application reference events in the
server application. Do you know of any examples where I can see a server
application raising an event in a client application?

Thanks,
Trevor Braun
 
I've looked at the remoting stuff, and gotten a sample (remote DLL) working,
but still not across applications.

I'm lost as to how I can have the client application reference events in the
server application. Do you know of any examples where I can see a server
application raising an event in a client application?

Thanks,
Trevor Braun
 
This is where things can get complicated, depending on your application
needs. If you are using remoting, it may be better to forget about using
events in the conventional sense. Instead, I would suggest designing the
system so clients call a "subscribe" method on the service. The service will
then maintain a list of subscribed clients, and when needed, sends a
"message" to the client. Problems may occur if for some reason, sending this
message fails (e.g. network problem, or client machine crashes, etc.) Then
server would need to handle exception and remove client from list. But what
if the client is still reachable, and the problem was temporary. Now they are
not receiveing the events? Probably a few solutions, one would be to have the
client send a mesasge to the server if it had not received a message for X
intervals.

Enough rambling though. If you are looking for specific remoting answers, I
would recommend you post a mesage on the
microsoft.public.dotnet.framework.remoting group, as Ken Kolda and Sam
Santiago generally give very good advice there on a lot of remoting queries.

HTH
Dan
 
Back
Top