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
>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
[quoted text clipped - 10 lines]
> Thanks,
> Trevor Braun
Trevor Braun - 30 Dec 2004 21:21 GMT
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
>I believe that with .Net you are going to have to use remoting to do this.
>My question for you is:
[quoted text clipped - 18 lines]
>> Thanks,
>> 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
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.
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"?
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

Signature
www.richardgrimes.com
my email evpuneqt@zicf.bet is encrypted with ROT13 (www.rot13.org)
Trevor Braun - 30 Dec 2004 22:24 GMT
Thanks for the terrific explanation. I'll do some more research on the
remoting before I continue.
Trevor
>> I have a windows service that generates events when it finds certain
>> database information. That is, the service runs, and on a timer
[quoted text clipped - 31 lines]
>
> Richard
Trevor Braun - 31 Dec 2004 01:12 GMT
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 have a windows service that generates events when it finds certain
>> database information. That is, the service runs, and on a timer
[quoted text clipped - 31 lines]
>
> Richard
Trevor Braun - 31 Dec 2004 01:23 GMT
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 have a windows service that generates events when it finds certain
>> database information. That is, the service runs, and on a timer
[quoted text clipped - 31 lines]
>
> Richard
Dan Kelley - 31 Dec 2004 09:43 GMT
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
> I've looked at the remoting stuff, and gotten a sample (remote DLL) working,
> but still not across applications.
[quoted text clipped - 41 lines]
> >
> > Richard