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)
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 am still pretty much new to c# so you will have to bear with me.
I have developed a windows form program which updates some SQL records as an end of day process for one of our clients.
The next step is that I need to install the program on a server and simulate a button click in the program to become a scheduled task.
I know how to setup the task on the server side where you start program and enter the arguments. But I am unsure as to what code I need to include in my program to achieve this.
Consider using Windows Task Scheduler.
You could extract your business logic to a separate DLL and write a simple Console app that will just run your task after accepting the parameters through command line.
My recommendation would be to get away from running a GUI-based/windowed application from a scheduled task - this is generally madness in practice. Ideally, deploy a console-based version of your application that requires execution (perhaps with parameter arguments) and doesn't require any user (or quasi-user-) interaction.
If you simply can't create a 'system version' of your application, then I guess you have two choices, both immensely ugly: 1) create some kind of macro script which is executed instead of your program, this script could execute the program and issue 'the click', 2) perform 'the click' on startup of your application by invoking the button click handler (maybe based on a parameter to give it a duality in execution modes.)
I think you are also asking about command-line argument passing. See the answers to this question.
In particular, I highly recommend the accepted answer: NDesk.Options.
I have similar task to do making winforms as windows task. what i did is
in windows task scheduler in the task tab,under Run put your exe and then /Auto,it will run as schedule.
Example:winform.exe /Auto
If I'm understanding your question correctly, this is how you could possibly proceed:
Best way to parse command line arguments in C#? -> check the answers and choose a library to process the args or write your own code to do so.
Create a scheduled task if those arguments are present by Creating Scheduled Tasks
If it is a windows application, just go to the bin folder, get the executable file, and finally schedule a task for it by using windows schedule task and choose the exe file as you targeted application.
if it is web application, you may want to include your code in a quartz.net scheduled job, details are on quartz.net website.
Very popular solution is Quartz.NET http://quartznet.sourceforge.net/
Take a look in the Timer class
http://msdn.microsoft.com/en-us/library/system.timers.timer(v=vs.110).aspx
Why not extract your database update logic as a windows service
you can segregate the sql handling part in a separate DLL and use the common DLL for both your form application and the windows service.
A window service run in background and can be automatically started when the computer boots, can be paused and restarted, and do not show any user interface.
Moreover you need not to install any third party software for same and window service code base can be ported to any windows machine with required version of .Net Framework installed.
Add reference: Microsoft.Win32.TaskScheduler
then write this code:
using (TaskService ts = new TaskService())
Microsoft.Win32.TaskScheduler.Task task = ts.GetTask(TaskName);
task.Run(); //start
task.Stop(); //End
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.
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 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.