0

I have a C# desktop application which has some user input fields and 2 buttons - START & STOP. On clicking START, it will connect to a server/external device. Once connected, the user can input data and send the information to the server/external device. Now I need to create a Windows service to automatically START and STOP the connectivity with servers. I mean a service to establish the connection with the servers (as START button does).

Currently I have added a new Windows service project in my solution file. Now my solution file has two .exe files. First one is for building the user application, and other one is to build the Windows service.

My actual question is: Can I write the START button's click event code under the Service1.cs files's OnStart event (to automatically START & STOP the servers)?

Matt Davis
  • 45,297
  • 16
  • 93
  • 124
user3894187
  • 35
  • 7
  • Why are you wanting to use a desktop application for this? – Andrew Barber Aug 05 '14 at 04:10
  • we have some more input fields on the UI apart from START & STOP buttons. So only start and stop should be controlled by windows services. – user3894187 Aug 05 '14 at 04:14
  • You're thinking about this all wrong. Your service should be making the connection itself. Not your desktop program. Then your desktop program should be sending the commands to the service. Services should not need to interact with the desktop. – Andrew Barber Aug 05 '14 at 04:36
  • @AndrewBarber, with respect, there are legitimate reasons for having an application and service interact with one another. The project I work on does this very thing. Please reopen the question so I can provide an answer. – Matt Davis Aug 05 '14 at 12:19
  • @matt Oh yes; they can definitely interact. Services.msc and net are examples where they do. A service can even interact with desktop processes, but that's not a good idea. From what the OP is saying, it would be far better to move the functionality to the service, and use the desktop app only for control. – Andrew Barber Aug 05 '14 at 12:21
  • Do you want the service to send commands to your application or do you want your service to perform the same thing as your application? Just off the top off my head the first one can be solved with Named Pipes for instance, and the second can be accomplished using a shared library, and having a shared class that performs the actual communication with the server. – Patrick Aug 05 '14 at 12:57

1 Answers1

1

The answer to your specific question is no. Since the Start button resides in the user application, the Clicked event will be triggered and handled there, not in the Windows service.

In order to control your Windows service from your user application, you'll have to use some kind of inter-process communication (IPC). This just makes sense, right? As I've already said, events in the application will not even be visible to the service for the service to act upon simply because they are two different processes. This is where IPC comes in. As the user interacts with the application, the interactions are translated into commands that are sent via the IPC mechanism to the service so that the service can perform the logic dictated by the commands. Likewise, results from the service can be sent via the IPC mechanism to the application for display to the user.

There are all kinds of IPC mechanisms - sockets, remoting, pipes, shared memory, etc. For .NET-based software, the recommended approach is the Windows Communication Foundation (WCF). In a nutshell, WCF allows you to define a programmatic API specific to your usage for exchanging information between more than one application domains. In essence, you exchange data by simply calling a method. From the developer's perspective, it's simply a function call. How the information is packaged and sent to the other application domain is dictated by how the WCF plumbing is configured. Want to use sockets? Want to use pipes? Want to use HTTP? All of these options (and more) are available by simply changing the WCF configuration.

I've used WCF successfully, but the learning curve is admittedly steep. In fact, I've fallen back to using sockets as my IPC mechanism for performance reasons. Still, WCF is worth a look because you don't have to worry about the intricacies of the chosen IPC mechanism. I've answered another question dealing with this here. It should get you started.

HTH

Community
  • 1
  • 1
Matt Davis
  • 45,297
  • 16
  • 93
  • 124
  • In the button click event i have a start() method which in-turn calls a function in my class library. so if i share the class library with win-service project and call this start() method in my service , will it make any sense? – user3894187 Aug 06 '14 at 09:52
  • If you're asking whether calling the `start()` method from the UI will trigger something in the service simply by referencing the assembly containing the `start()` method from the service, the answer is no. This is where IPC is necessary. However, the service can certainly call the `start()` method of its own accord, but sharing code in this way does not facilitate communication between processes. I hope that answers what you've asked. – Matt Davis Aug 06 '14 at 13:28