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
Related
I have a WPF application that should have been designed as a service since I realized that when the user logs out, the application closes. The WPF side has just a few settings such as DB name / password, OAuth token that is needed by the service. What is the best way to transfer that info from the WPF view to the Windows service? I had thought I would use registry settings, but it looked like that is getting phased out with UWP so I figured I would learn what the new "right" way was.
I would of course not want to store DB info in a plain text file.
What is the best way to transfer that info from the WPF view to the Windows service?
You could basically create a new Windows Service (.NET Framework) project in Visual Studio and move your current code over to this one.
For more information about how to create Windows services, you should check out the documentation on MSDN:
How to: Create Windows Services: https://learn.microsoft.com/en-us/dotnet/framework/windows-services/how-to-create-windows-services
The service may connect to the database in the same way that the WPF application does since both are based on the same version of the .NET Framework.
If you want to share data between a client app and the service, you could for example use a database. You might use a local database or a plain file if the service and client app are deployed onto the same machine, or you may use a remote database if thet are not.
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.
Im looking at creating a service on a remote server that a win forms app can communicate with. (Where the forms app is running locally on user machines).
The service can either run in IIS (7.5) or as a windows service, but essentially I need to be able to call the service from the forms app and then have a stream of progress sent back to the forms app from the service, much like you would output to a Console window.
I've looked into using WCF which seems ideal except I couldn't find out whether I can relay progress updates back to the forms app. Also SignalR running as a self hosted windows service seems to be an option but might be overkill?
We'll be running the forms app on win7 and the remote server will be running server 2008.
Are you able to advise best routes to go down for this and if possible some examples or tutorial links?
Many thanks :-)
If you are looking for the application to relay back to the server for progress, seems you are looking for something like this:
WCF Duplex
It basicly enable you to call bi-directional function using open socket.
Hope it helps.
Thanks,
Amir
How can I load a 'login form' in OnStart event of windows Service?! I know windows service is incompatible with UI. but I need to do this without using windows startup..
Is it possible? and how?
Thanks a lot.
How can I load a 'login form' in OnStart event of windows Service?
You cannot do this, because Windows services cannot display a user interface.
I know windows service is incompatible with UI.
Oh. You already knew that. Good.
but I need to do this without using windows startup..
This does not change the fact that it is not supported and will not work.
Is it possible? and how?
No, because:
windows service is incompatible with UI.
So what do I do!?!
The real answer here is that your design is wrong.
If you need someone to log in to your application, you should not be creating a service.
Just make a standard Windows application (e.g., using Windows Forms or WPF) and set it to start automatically when any user logs on to the computer. This can be accomplished easily by adding a shortcut to it to the All Users "Startup" folder.
Then, when your app runs, you can display whatever UI you need to, without the limitations of a service.
If you need to combine UI interaction with a service, you ought to write two programs - the service, which exposes some kind of API, and a client program that interacts with that API (using whatever IPC mechanism you want to choose)
Just remember that multiple users can log onto the same machine, so you ought to write everything to cope with multiple instances of the client program running at the same time.
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.