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.
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 am trying to run a background service which just writes to a file on a specified interval.
There are two methods that I tried
1) Created the project with the Console application template
2) Created the project with Web Application as template
When I run the app from visual Studio, both of them run fine. But when I deploy them to IIS, only the web application version works. It must be noted that there is absolutely no difference between the code of the two projects. I have used the WebHost as a hosting strategy in both the projects as well as well as installed all the dependencies in case of Console application as there are in the Web Application version.
I must also inform that I have used the preloadEnabled="true" option in IIS as IIS needs a web request to start the application.
I am wondering what is the difference between both the project types as the code is the same? I don't want the Web Application template.
Edit 1: I forgot to mention that the service will also need to expose an api endpoint for healthcheck purposes. Will the windows service approach listen for http requests?
I used the following article for implementing my background service.
https://learn.microsoft.com/en-us/dotnet/architecture/microservices/multi-container-microservice-net-applications/background-tasks-with-ihostedservice
After years of building background services, I learned that Windows services are the best tools to implement these applications. While there are different techniques to keep an IIS application up and running in the background and prevent it from getting recycled, in practice, the applications on IIS are not meant to be executed forever.
If you had an intention to build your app in the cloud, I would have suggested using something like Azure WebJobs or Azure Functions Timer-Triggered functions, but for on-premise, even using something like Hangfire in the web is not sustainable. The worst happens when you need backward compatibility on Windows servers that don't have the "Application Initialization" module.
My suggestion is to move your application to a simple Windows Service if you control your environment. Windows services consume less memory, are easier to manage, and can run forever without getting recycled.
WebApplications are plain the wrong tools for this.
Being always on and always reachable, WebServers are primary targets for hacking. To compensate for that, they are usually run under the most restrictive user rights you can imagine: Read rights to their programm and this instances content directory. While I do not know why it worked at all, it propably will stop working in Production.
What you wanted to write was eitehr a Service or something executed by the Windows Task Sheduler. Personally I advise for the Task Sheduler as Services have their own set of restrictions. Unless of coruse there is some detail of the requirements that you did not told us.
This article could be helpful. It's a step by step tutorial on how to convert a console application to a web application.
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.
As in title I would like to ask what is difference between using these possibilities of hosting my code on Windows Service. As far as I can see, all three allow me to create exe which will be installed as a service.
Topshelf is my preference because it allows you to get the best of both worlds a service and a console application. Using sc.exe allows you to execute any console application as a service, but the exe doesn't interact as a service itself. Developing a Windows Services directly let's you have a service and interact as one with Windows, but it isn't easy to debug or run as a normal console application. Topshelf allows you to ge the best of both running as a Service and running as a normal console application.
Windows Services are special application types that respond to service control messages like Start, Stop, Pause, Continue etc.
While it is true that you can use something like sc.exe to turn any kind of process into a service, those processes will not handle the previously mentioned control messages. What you will commonly find is you'll be able to start a process but not stop it etc.
What I tend to do is abstract my services out (I think Topshelf does this), have a service library that can be loaded by a native Windows Service application or a console application so that I can have the best of both worlds (usually debugging under console).
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.