I have created a windows service to serve as an "input manager" to a system. What is does is not really important. It just reads records in from a SQL server table, transforms the data into a new form and puts it in another SQL server table.

What I would like to do is create a service control program that can talk to my service and get information on what record is currently being processed and, perhaps change processing settings.

I looked into creating a Sevice Controller Program (SCP) but you really can just start and stop the service and send it an integer as a command with the ExecuteCommand() method.

As I said, I want to do more. Ideally, I'd like to setup a deal where my service has public properties and methods that can be called from an external "control" program. A sample property would just tell me what record is being processed. A sample method may be to tell the service to backup and start processing at a previous record for some reason.

The solution, I would think, would be like an old COM Server. An .EXE that one can get a handle to and the access the methods and properties. In COM you could do this with GetObject() for example.

I have considered writing TCP listeners and have also thought of DCOM, but it seems unnecessary to me if the programs are running on the same machine. I have also considered using Message Queue, which, again, seems like overkill.

An easy solution, of course, is to communicate through a SQL table. However, it seems like a waste to talk between programs like this when I ought to be able to locate the process running in memory and strike up an interprocess communication in memory.

Does anyone know of a way or how in .NET you can have two separate processes talk to each other like a COM Server. Again, these were the good old days, but I used to be able to open MS-Word, for example, and then run a VB program using the GetObject command that got a handle to Word, and then I could give Word commands. When I closed my VB program, Word would still be there. This seemed to me like interprocess communication of separate processes, but maybe I was fooled.

Anyway, does anyone have any suggestions? I know I can do this a variety of ways, but there has got to be a better way than using TCP (like SQL Server Enterprise Manager), DCOM, or a shared table.

Thanks!
Hubman

After doing some more looking into Remoting, I am now thinking the way to interact with my Windows Service is through Remoting. However, this looks to be a fancy built in TCP listener, which I was wanting to avoid.

If I don't hear from anyone, I will probably purse implementing Remoting in my Windows Service.

Hubman