1

I created a Winforms C# application to spawn threads and run jobs on our production server. I created the jobs in a winforms application because I need a GUI to configure and run the services.

We recently changed servers and I'm logged off after a certain amount of idle time and the application is shut down so I need to make Windows services to keep it running even when I'm logged out. The problem is I need the GUI.

What's the best way to create windows services (because I need them to run when I'm logged off) with a GUI interface?

Eitan
  • 1,307
  • 5
  • 20
  • 44
  • 1
    [Inter-process Communication](http://stackoverflow.com/questions/56121/ipc-mechanisms-in-c-sharp-usage-and-best-practices). – ta.speot.is Jun 04 '12 at 06:55
  • @ta.speot.is is correct, you'll probably need to split your application into the GUI part and the service part that needs to run without the GUI when logged out. You can communicate between these processes with inter-process communication. – kenny Jun 04 '12 at 08:44
  • What's the best way to do this? WCF? Is there an easier solution or 3rd party software to facilitate this quicker? – Eitan Jun 05 '12 at 09:59

3 Answers3

0

If you create real Windows Services

you can start, stop and get information about the service by using the ServiceController class

EDIT

If you need data from the service, you could use WCF or a Socket to communicate with the service. Another option is to publish the results of the service in a file that is in a well-known folder.

Emond Erno
  • 48,121
  • 11
  • 77
  • 106
0

Spawning a windows service in the user session (= Interactive Windows service) is not a good idea and considered as an exploit. I solved this problem in my project by splitting the application in a GUI and a Service-part, just like kenny said. They communicate via WCF. Another possiblity are Memory-Mapped files.

0

If you want a simple way to talk between your processes you can also use NamedPipeServerStream and NamedPipeClientStream. This technology is old, not really clever but easy to use (if you know stream management in C#) and fast.

The only drawback is that they do not talk Object out-of-the-box. But for that purpose I use XML Serialization.

  • On the sender side : Object => XML String => byte[]
  • On the receiver side : byte[] => XML String => Object

To keep it simple I always use String[] objects which I parse on the receiver side like I would do in the void main(String[] args) of an application

With services you can also use CustomCommands, but this only ask the service to spawn a method without giving it parameters. Except if you store parameters somewhere (ie: an XML file) where your service have access to them

Sebastien GISSINGER
  • 625
  • 7
  • 18