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.
Related
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 want to execute "start [Filename].txt" at fixed interval.
So I decide to create windows service.
But I am not getting idea to execute this command through windows service.
Other logic i have implemented. Just remaining is execute command.
I think you can simply use:
Process.Start("filename.txt");
If you need to start that file and wait for it to close or some other particular action, take a look at Process Class.
Process.Start("filename.txt") will work as #Marco answered
I'm wondering if you could get away with a Windows Scheduled Task instead of a service.
Is that all your service does?
Create a PowerShell script and have it executed on schedule by task scheduler...
Process.Start will not accomplish your likely goal if in a Windows Service. It may launch the process....into session 0, so you will never see it. To launch a process from a service that the user can interact with, you will need to create the process in the user session, a pretty non-trivial thing to do from inside a windows service (but certainly possible). You might be best to look at a Windows Scheduled Task as #jglouie suggested.
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)
Background:
Started a fair amount of work before realizing that a Windows Service cannot start an app with a GUI that displays without potential problems. The proper solution of separating the GUI of the app to be started is non-trivial, so I'm trying to think of alternative solutions.
There is a GUI to manage the service that is a separate executable, but the process to be launched (actually multiple instances of it) has its own GUI that needs to be shown. It doesn't need to be made visible by the service itself, but it needs to be at least able to be made visible by another process with a visible GUI. The Windows User that is running the service and that needs to see the GUI of the launched process is the same and known at install time.
Is there some way to accomplish this or is it back to the drawing board?
Also both the service and the app to launch are both our code and modifiable.
My first thought was to suggest that you look at the WTS* functions and CreateProcessAsUser and then I followed the link you provided and saw that you have already considered this and dismissed it.
As an alternative, if I understood you correctly you have a Windows Service and GUI which is used to manage the service. So why not use the communication channel you have between the Service and the management GUI to send a message from the service to the management GUI and have the management GUI launch the other GUI apps on behalf of the service? Of course this would assume that the management GUI is always running.
You might even do this with a hidden application that is not visible and launches when the user logs-in, that way you reduce the risk of the user inadvertantly closing the application, this would be a separate app from the actual management application.