I’m currently writing a windows service that’s sole purpose in life is to poll a database and, based on the resulting information, update some other data. I wrote this as a windows service because it seemed an ideal platform. I don’t need any user interaction.
However, while developing it, I’ve noticed one or two issues that make developing a windows service more time consuming that developing a straightforward windows app. Has anyone has any experience with this kind of choice? What is the best practice for this kind of app? Are there any reasons why using a windows service is preferable?
The issues of development imoho are far out weighed by the features that services provide. Remote polling, no need for a user to log on, built in fault recovery and monitoring.
I just made my first service too and noticed they are not quite as easy to debug or test. You can install and start the service then attach the debugger to the process. Or you can run the service as a console app just to test out functionality. Something like this http://tech.einaregilsson.com/2007/08/15/run-windows-service-as-a-console-program/
Whether a service is preferable or not is your call. rerun listed good reasons for services. Based on your description it sounds like a scheduled task of some SQL would accomplish what you want.
To debug a windows service directly under visual studio , Add this Code snippet to your service designer class under Main() .
Shared Sub Main()
#If DEBUG Then
Dim service As New YourServiceClass
service.Execute()
System.Threading.Thread.Sleep(System.Threading.Timeout.Infinite)
#Else
Dim ServicesToRun() As System.ServiceProcess.ServiceBase
'More than one NT Service may run within the same process. To add
'another service to this process, change the following line to
'create a second service object. For example,
ServicesToRun = New System.ServiceProcess.ServiceBase() {New YourServiceClass}
System.ServiceProcess.ServiceBase.Run(ServicesToRun)
#End If
End Sub
This is vb.net code but C# should do the same trick. I have managed several windows services like this without any issues. If debug should be preceded with a hash.
One thing you should be aware of is that a service will not be able to use video hardware acceleration. If you are not doing any graphical work then you can safely ignore the limitation, but if you have graphical-intensive operations (for ex. WPF-related) you have to keep this in mind.
I admit it's not a common scenario, but I've worked on a project where a service rendered WPF controls.
The reason for this is Session0 isolation, described here.
Related
So I have researched through MSDN and SO, but have not found the answer to a question asked quite this way: I have an app that will be turned off/on, and as part of the install/update, I want to have a Windows service get updated as needed also as part of the install to the primary app. The Windows service will provide data to the app, but if the app changes, the service may need to provide more/different data.
I looked at TopShelf as someone suggested on a different post, and seeing that makes me wonder if I can use TopShelf to deploy the service at the same time as the app itself - in other words, wrap the whole thing in ClickOnce, let TopShelf do the Windows Service part, and ClickOnce finish by doing the app part. Does that sound like a decent strategy?
Ok, so I found my answer: ClickOnce doesn't do what I want, because Microsoft said so (under "Next Steps"). But their suggestion is to include a class called ServiceController which can talk to your service from your application, and do any Service manipulation that you want. (TopShelf doesn't appear to be necessary.) I like this because it allows everything to be under one roof, and is elegant...It should solve permissions issues and other barriers to simplicity of installation - we want this to be as easy and seamless for our
customer as possible.
This is my first time dabbling in windows services.
I have a service I would like to manage, I would like to be able to connect to this service via a command line / REPL of sorts to avoid the development time of working on a user interface. I was thinking we could communicate much like attaching to an Asterisk daemon or somewhat like connecting to a MySQL server which to me seems like nothing more than a simple custom shell spawned to handle requests. However, I am always concerned about how efficient my code is and would like to keep to common practices. This will be connecting on the same local machine.
My proposed solution:
I believe I can make simple network stream, to create a simple Read - Eval - Print - Loop.
Another option is to use WCF, however my question would then be, how efficient is this as opposed to packet handling?
My question:
What are some standard practices for communicating with or managing services on the local machine?
I'm trying to learn more about service-oriented design, any resources that could help explain common practice models would be much appreciated.
Of course there are so many ways to do this. The way I would recommend is to make sure you use log4net (or some other logging framework) and log the important info. Create the solution with 3 projects, the first will be the "service logic" or the business service, with the second being the windows service wrapper that starts that service, and the third being a console app that does much the same as the windows service only giving you the ability to interact as you wish. The advantage of the console logging appender is that you still get the console output without actually writing to the console... it give good separation.
I will give another option that I have used in the past, but would give with caution. You can selfhost a WCF service inside a windows service. It gives a nice interface that gets away form the messy self rolled TCP server approach. The caution is that if done wrong it can eat up lots of memory and CPU cycles.
We are faced with the problem maintaining lots of windows services.
The idea is to reorganize windows services in to class libraries and connect libraries to one master windows service. Is there a good idea ? Any advices please)
There is a framework for hosting "services" within a single Windows Service called TopShelf. You might want to consider using that. https://github.com/Topshelf/Topshelf
I am interpreting your question to be "We have tons of little Windows applications that run as services - how can we simplify them?".
In general, lots of smaller programs are better. Single monolithic applications are difficult to maintain and test; when someone needs to make a small change it can trigger catastrophic consequences for dozens of other components of the application. It can also make it impossible to change one small application without taking down the whole service, as Chris Knight comments above.
On the other hand, lots of small programs suffer from the breadth problem. You probably want to make sure all your little programs run on a consistent framework - i.e. they all log their results to the same place, they all use a standardized configuration system, and they are all managed in the same place.
I have seen situations where people write services because they need to run a task "when a particular condition happens", so they make it a constantly running service and continuously check for that condition. Is it possible that you could take some of your services and turn them into triggered launches of individual applications?
If this isn't the correct interpretation, please let me know :)
I've made a windows service with a timer (I've seen discussions about timer-driven windows services vs windows task scheduler, and still want to go with my own windows service) that runs some business logic.
To separate my concerns and make it easy to test & run manually, all my business logic is in a separate project that I also reference in a windows forms tester GUI.
Now I want to make another timer-driven windows service in another solution that runs some other business logic, so I'm thinking I don't want to end up with several codebases for my windows service and timer, so I'll reuse them from this solution, and go write my other business logic project.
How does this work? Am I going to end up with the same DLL name for the service project in both solutions? If they run on the same server, that will cause problems. It's such a small piece of code, I almost feel like the service isn't worthwhile as its own project, or isn't worthy of reuse, but I also hate the idea of not reusing it.
Also, I dislike the notion of reusing, say, just one or two .cs files and not the whole project, not only because that seems like it goes against the intentions of .Net, but also because our Mercurial source control makes that cumbersome.
What's the right way to approach this?
I've written a console app that sends MS Reports to emails.. (the reason was that i could check it easily if it works)
I want this to run daily at 6 am.
My idea was to write a service (so nooone will need to be logged in and the service will run).
So I'd like to call the static Method directly in a WebService.
I've a solution with 1 project file that is my console application (with settings, many references.. etc). I'd like to add another project - Windows Service.
My question is.. how to do that easily, so I wouldn't have to copy all classes etc to the Windows Service project?
Or am I totaly off the way? :)
Thank you!
Sounds like overkill to use a Windows Service to send an email once a day. Why not just schedule a task in Task Scheduler?
You're going to have to refactor your app. I'd recommend three projects -
Console App - instantiates and performs any neccessary set up on your business logic object then routes all output to the console. Use this for debugging and testing
Business logic - Extract all the logic of your application into this class.
Service - Basically the same as the console app except that I would recommend sending any errors to the global event logger. That way if your service bombs you can find out why.
You can use this pattern for any other services you develop.
Create a class library and put the shared classes in that library.