I'm coding a console application that is reading and writing some stuff at different intervals during the day. I want this later (if its "final") as a service. For now a simple console application is better (that's how I thought) because its easier to use and I can see the result without having to register/start/end the service. Is it easy to later, if I'm done with the testing, just create a new service project and copy the code from the console application?
I heard now that we should not use Timer in a service. But I'm using System.Threading.Timer in my console application a lot. Does it mean that I'll be in trouble? Is it this "testing on console app and then using it on service" thing not a good idea? Any suggestions?
You can create Windows service and Right click->Properties and change Output Type as Console Application do your developement.Once you have done with development change back Output Type as Windows Application.
Take a look at this link to know deep about the both timers.
The problem with System.Threading.Timer is that there's no easy way to start/stop the timer. And because of that, you can't realiably use it for tasks which could possibly take LONGER than the timer interval.
Switch to System.Timers.Timer instead:
http://netpl.blogspot.com/2010/05/systemwindowsformstimer-vs.html
A good solution for you - is to try Application As Service software
You can launch every application as a service.
Related
I have two application modes one is Console application and Windows Service both suppose to do the same job console will take user inputs and base on user inputs it will proceed with intended task and user inputs will be saved as user settings.
I need Windows service to use the same settings and do the same task in background with scheduling. Currently I'm facing the problem where user settings are not available when reading from Windows Service.
You can save the user settings (at time of running console app) in an XML file and read that file in your windows service and work accordingly
There are 3 possible routes that I can think of to deal with this issue (I will update this later today with more detail when I have more time).
First, combine the applications into a single Program. Modify Program.cs so that you can pass in an argument telling it to run as a Console application or Service. This method helps you to make sure that you are doing the same thing in both uses, without repeating a lot of code.
Second, share the settings file between both projects. This seems to be the basic question you are asking. I'll elaborate on this when I have more time this evening.
Third, ask if you really need the service for what you are trying to do. If the service is only being run at certain times of the day, it might be better to instead focus on allowing the Console application to also run without input, as a Scheduled task.
I built a C# desktop application that will run on some time trigger.
I want to consult with you what should be my 'driver' project?
A winService? How should I set the trigger?
The accepted answer here is a little confusing. The simplest way to achieve what you want is to use the built in Windows Task Scheduler to launch your application at a specified time each day. There is no need to write a Windows Service. In fact, it doesn't even make sense to talk about running a service under the task scheduler, as by definition a service runs continuously.
However, a service could be another way of achieving what you need. The service could define a timer which fires once a day and performs any tasks required. Be aware that a service cannot have a UI - it just runs in the background. It can also be a little more challenging to write than a desktop application.
More about services here: http://msdn.microsoft.com/en-us/library/d56de412(v=vs.90).aspx
You can create a windows service and then set it to run using the Task Scheduler. This would enable you to run your application at a certain time everyday, depending on how you have set it up. Although the downside of this is that a windows service cannot have a UI. But if you just want the Task Scheduler to run your actual desktop application then just do that.
I wrote a windows service that resides on a windows 2008 server. I also developed a separate C# winforms application that I'd like to use to configure a task for the service to schedule its run.
The winforms app is a form UI with basic scheduling inputs such as day of week, time of day, etc. I'd lke the user to choose inputs and save this as a task that will schedule the running of my win service.
Is there a way to add/edit a windows scheduled task via C# winform without using 3rd party add-ons?
Alternatively, you could write the service to always be running, and have it reference a database table on when it should run. The service would simply check when it is allowed to run.
Your WinForm application could simply update the database table. Quite simple really. Of course you could make it infinitely more complex, but, for what you are describing seems relatively simple.
I don't think there's a way using purely managed code, but if you add a reference to the TASK Scheduler COM Library, you should be able to do it. (References... Add Reference... Com Objects)
I am doing windows service to check another exe is running or not. If not running, I need to start this exe again. I use the timer to check every one minute. But Timer doesn't work.Please give me advice.Although the service is running, no code in timer is working.
Thanks.
We need the code to help you.
Which timer did you use? There are three and they all have a different way of working. Windows forms timer needs to be started or set to start on load if that is the one you've used.
Other timers have different properties but you might run into issues with the reference being garbage collected.
BUT
All that aside, it sounds like you want to implement your EXE as a service, that way if it crashed you can set windows to restart it for you. If you wrote the exe you're monitoring, I suggest you look into it.
MSDN Windows Services
EDIT: Also you may wish to look at SrvAny which will convert any executable into a windows service for you. Its part of the windows server resource kit.
The original poster has probably fixed this problem, but a very common mistake when it comes to Windows Services and Timers is to use the System.Windows.timer and not the System.Timers.Timer which is the one you shall use.
Just posting this in case someone else comes over this post and maybe this answer will help.
Is it possible to wrap your service around the exe itself that way you can take advantage of the service being able to restart itself thus restart your exe?
I have done this with a WCF service but im sure it would be possible with any process. So onStart of the service run your exe and wrap it in a try catch. then if it fails just restart it. Also if the service fails itself you can get it to automatically restart (option available to all windows services).
I have a GUI C# Windows form program that I would like to start as a service when the computer starts and perhaps have an icon in the system tray that when clicked maximizes the program. Is this possible without major rework?
Thanks
Windows Services cannot have a GUI, at least not directly. You will have to separate your application to a presentation layer/process and a service layer/process:
The presentation layer will remain a WinForms application
The service layer will run as a Windows Service
The two of them will have to communcate with each other with some means of inter-process communcation, like named pipes or sockets.
You can use a third party app, such as FireDaemon (http://www.firedaemon.com/), to start any program as a service. There are many options available in FireDaemon, such as form visibility, restart on failure, etc. However, it will not automatically create a tray icon for your app. So your app will have to be changed to have its own tray icon functionality and FireDaemon will just start the program and manage the process.
FireDaemon costs about $40 (USD). I imagine there are many other similar applications available.
I would first look into creating an actual service project as mentioned by other answerers, but keep this approach in mind. It has worded well for me in a handful of situations.
It depends on how the code is currently written. I have several WinForm apps that double as services, but the bulk of the work I have separated into another assembly. My solutions for those apps generally have 3 projects: WinApp, Service, and Library (I'm oversimplifying here).
If you feel that your WinForm app could make a good service then you probably have your code in such a state that you could probably separate it out easily enough. Adding a service project is pretty simple, adding the installer for it is a little more challenging but still well documented. The trickiest part is making a deployment package for it that installs the service properly, but again... its well documented as long as you know you need to look for it.
Edit: Just to clarify, in general I wouldn't consider this a major project.
You can write the code to have it run as a service, but I think the more important question is, what does it provide? There are ways of minimizing an application to the tray, and you can start said applications at launch to the system tray.
This is the link that I always refer back to about doing windows services. It is WCF based, but I think with a little modification you could make it work for you:
http://support.microsoft.com/kb/317421
As to minimizing to a tray, there's an excellent answer in this question:
What's the proper way to minimize to tray a C# WinForms app?
You could use Task Manager within windows and setup a task that would execute your application's .exe per windows boot.