suppose i have a windows service which does some work and developed by c#. now i want to develop a another win apps with c# which control & interact with my win service. suppose i want to start/stop my win service from my win apps or i want to run a specific method of my win service from my win apps. how to develop this type of win apps which can interact with my win service. please discuss in detail.
thanks
You may find the following article useful.
For starting and stopping see ServiceController class
http://msdn.microsoft.com/en-us/library/system.serviceprocess.servicecontroller.aspx
You can also pass parameters on start.
For controlling use the ServiceController class as stated by the other.
Do make your service to do something special controlled by your app you have to set up a kind of communication. I would suggest your service listens on a certain port for http request which can be handled fairly easy and so your service might be controlled by any kind of app even javascript ajax. If unwanted add some security like authorization.
For communication between a Windows service and a Windows application, I use Windows Communication Foundation (WCF). In my Windows service, I host a WCF service that "listens" for incoming requests. My Windows application creates a WCF client that communicates with the WCF service hosted in the Windows service. From a programmatic point of view, the WCF client invokes methods on the WCF service. All of the behind-the-scenes complexity is hidden, so from a programmer's perspective, it looks like you are simply making a function call.
To start and stop the service, I use the ServiceController class. Note that this class has certain security requirements. A user with limited system privileges will be unable to use this class directly.
You need to be aware of security.
Using the ServiceController class gives you some limited ability to control a service (start/stop/pause/resume and send simple commands), and has the advantage of being secure. Typically only Administrators (and maybe Power Users) will be able to control the service although you can configure permissions.
If you need something more flexible, you need some form of inter-process communication to communicate with the service - and WCF is a good option in the .NET world as described in Matt Davis' answer.
However in this case you need to implement your own security, assuming you don't want to allow just anyone to interact with your service.
Related
I need to have a windows service that is configured with simple UI. I understand, that I need to create an API for windows service and use it in separate desktop application. But whatever I google I just got "you can't create UI to windows service" or info about webservice. I found this https://www.codeproject.com/Articles/1159908/Yes-I-Know-But-I-Still-Want-a-GUI-for-my-Windows-S but this seems to be a pretty bad workaround, because I can't use already started service in my GUI using it. What I need is some code, explaining how to create a connection between these two applications
I have a WCF CRUD REST API up and running in a Windows Service. All is well.
I'd like to offer the user the ability to run that inprocess as well; so, instead of running a service (which would require admin) I'd like to have a static library version as well.
With .NET (C#) how would I go about this? Right now I have:
ServiceLib (interesting code)
ConsoleHost
GUI
I'd like the GUI to selectively be able to run the ServiceLib code as a full-fledged Windows Service -OR- just as in-process code. The service way already works, which I assume is harder.
If you run it now in a Windows service it's already self-hosting, I assume? If GUI app will be the only one using the service in the "in process" mode you can split your "WCF CRUD REST API" ServiceLib into two - one implementing CRUD part and second implementing WCF REST API on top of it. In GUI you'll need only the CRUD part, so no need to bother with self-hosting of REST API in the same (and only) application that's going to call it.
Running a GUI app as a Windows service is usually a pretty bad idea anyway from the sysadmin's point of view. I often run console apps that can be either WCF hosting Windows services or just WCF hosts, but their only GUI is ablility to react to Ctrl-C.
I'm working on a project that consists of a web application where users can start long process of generating different types of files.
User wont be able to download the files, only can start the process and the files will be located on the server and this process could take several hours.
My Idea to solve this its a MVC App that is communicate with a windows service and this service start the file generation process.
I have some concerns about this.
based on your experience, do you think that is the best way to solve the problem?
What is the best and easiest way to communicate the web app and the windows service? this is a one way communication, web to service.
About the windows services; should the service do all the processes? or maybe its better if the service only execute console applications that do the generation o the different type of files.
I really appreciate your help.
Since Web API can be self-hosted in any process and a Windows service isn't an exception, I would recommend hosting both HTTP API and the long process thing in the same Windows service.
Use OWIN/Katana to host your Web API.
Use Topshelf to create your Windows service.
If you design and implement this Windows service using best practices, it should be a good solution, and you should think about how easy will be the deployment of your solution since you don't need IIS anymore.
I would go still with the IIS. This is because of its support. Have been using Web webservice to host long running background service for long time without issues. Only concern is to remove the default application recycling.
Of course your application will need to handle properly start/stop events.
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?
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.
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.
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
I have a WCF Service that I already mention in another question here. As I have read here host WCF in Windows service is the best solution for all reasons. So that's why I select this option. But windows service hosting doesn't allow any visual process communication (before we used self-hosted service, that have hosted in console application and report any problems just into console). How can I get similar way for hosting service? My thoughts is about using another named pipes binding for visual "communication" between service and human.
I would be very nice for me if somebody recommend me something useful.
Thanks very much in advance guys!
In case you need the "Screen" just so that the service can report the problems, the I would suggest that you use windows event to log such events from the service and then you can create any UI/back ground process that can look for such events in window event log and report them appropriately (ex: sending email etc)
I tend to agree with #Ankur's answer, but figured I'd give you an alternative option. You could consider using WMI provide visual feedback to a running service. I attended an interesting ALT.NET talk on the subject (not WCF specific) a while back (full video is available here) and it should be relatively straightforward to instrument your application with WMI to allow you system state to be queried