I have an application that is built as a Windows Service and a c# library assembly (.dll.) In order to manage and maintain this service, I'd like to add the ability to run a command-line application that tells the last time the service archived files, the next time it's scheduled to do so, the status of the last run, and the location of a file created by the service.
What's the best architecture for writing a service and library that can share data with another application? I'm using .net 2.0.
I use WCF for that and create a contract definition for the commands/events I want to support.
Options that spring to mind that I've applied in the past:
A fairly simple approach is to store that information in either a local config / text file which both apps have access to. Or even to place it in a registry key.
The best architecture is probably to make your service be a "server" that can report on it's status (and whatever information you want). Using WCF for this like ocdecio suggested would make it pretty simple.
The way that inter-process communication happens in .net is through remoting (even if both processes are on the same machine). Other responses have suggested alternatives to inter-process communication which would not require remoting.
+1 for just having the service provide that (and any other data) when it is queried (simple tcp, RPC, web service, or whatever)
I'd make it pretty generic - like
QueryInfo(some identifier) with a response as some string and a return value or other indicator that the service does not know what you are talking about, cannot get the info, or give back the info