So this is my first stint with programmatically creating windows service or scheduled tasks and I am confused which one to choose. I had a look at various articles like http://weblogs.asp.net/jgalloway/archive/2005/10/24/428303.aspx , scheduled task or windows service and some more but can' t really decide btween the two
Here is my scenario :
My application will pick up the code paths of a few dlls from the db , execute the DLLs using MSTest.exe and log back the results to the Db. this will probably be repeated every 2-3 hours . Now I am leaning a bit towards scheduled tasks since i won't have to worry about memory related issues but need some expert advice on this.
P.S. : The DLLs contain test methods that make calls to web services of applications deployed on various servers
Thanks in advance for the help
A Scheduled Task would be more appropiate for your scenario. I don't think it make a lot of sense building a scheduling mechanism on a windows service when OS already provides scheduling infraestructure.
A Windows service is more appropiate for processes that have to respond to events at any moment and not at specific and fix periods. That's why they are running all the time. An example of this is the SQL Server Service.
An exception of this could be a task that needs to run every second or so. In that corner case, a Window Service could be the best solution. For your specific schedule, I have no doubts that a scheduled task would fit much more better.
Although this post is several months old, here's a possible resolution in case it's helpful to others for the "Run whether the user is logged on or not" issue : start with a console project then change type to Windows App as mentioned at Run code once and exit formless app: Windows Forms or WPF... does it matter?:
“If you never show a UI, you should start with a WinForms project (WPF projects set extra project metadata that you don't want), then delete the reference to System.Windows.Forms.dll. Alternatively, start with a console project, then change the Output type to Windows Application.”
Related
I am having to design a client application that will be installed on all computers in our company that will collect and report hardware and software information for inventory purposes to a SQL database. The application may need to be updated remotely and possibly some parameters such as polling time period be updated remotely as well. I am not entirely sure of the best way to architect this type of application. In trying to research and think this through I have come up with the following options:
write a Windows Service that would always run automatically, anytime a computer booted up and on a Timer have it perform the necessary inventory functions.
write a Windows Service that acts like base platform for future expansions, but contain the actual inventory client in a Forms/WPF app that is minimized to the system tray and can be opened to change settings. The Windows Service would verify that the Forms/WPF app is always running and handle any management tasks such as possibly performing upgrades on the Forms/WPF app.
write just a Forms/WPF app that is configured to run on Startup. It would be minimized to the system tray and on a timer perform the inventory function and report to the database.
That is the three main options I have come up with. I'm hoping someone who has tackled a problem like this in the past can provide some insight into how they designed their project. Any advice is much appreciated.
In case anyone else has a similar question, the path I've ended up taking is to create a Windows Service that has all of its main logic in a separate dll and has a separate program for updating. The Update program stops the service, moves/overwrites the dll's for the service and then restarts the service. The main dll that the Service runs processes on a polling/timer feature and periodically checks for and downloads updates and then can schedule the Update program to run. I found a great example here.
Even though I've already chosen how I am going to implement this project, I am still open to hearing how others have handled similar situations.
I wrote a console application that is currently running on the server. It doesn't require any user input (other than parameters at start which can be done via start parameter).
Unfortunately this solution is bad, because someone can accidentally turn it off (i.e. when connecting to server using Remote Desktop Connection and then logging off instead simply disconnecting). I need it to run all the time.
One solution would be to turn it into windows service, but so far using SC or third-party tools like nssm or RunAsService failed (SC and Nssm create a service but such service cannot be started).
I could completely rewrite my program to be a proper service... but to be honest I'm struggling with it (and from what I've read its not recommended practice).
Finally I could leave it as a console app and use task scheduler to run it -which does look like a decent solution, but (like I've mentioned) I need it to run all the time (it can be turned off and on - very short downtimes are not an issue).
Could I please ask for any help with setting such task?
SOLVED
After few attempts I've turned it into service using Topshelf andthis great guide.
There are two methods you can use to run a .net program constantly in windows. Both have advantages and disadvantages.
Windows Service
Recommended Solution
Will startup service on computer start (doesn't require someone to log on)
Has some (limited) error handling in the form of restarts
Good for very reliable services that can run for long periods of time
Service handles its own state
Can easily crash due to memory leaks
IIS Application Server
Not recommended solution
Starts with windows, but might not start your application
Requires newer windows to allow always on configuration
Always on configuration is complicated
State is handled by IIS
Much better resiliency to crappy programming, as IIS will restart for you
IIS will also likely kill your threads for you (so your scheduler will stop working)
I suspect the reason you were told that a windows service is not recommended was due to the fact that it could crash due to memory leaks. But that issue will occur no matter what, since your program needs to run for a long time (its not a problem with windows services, but long lived processes).
There are a number of rules that need to be followed to write a functional windows service including but not limited to
the ability to complete the initialization process in a specific time
a general understanding of threads
There is nothing inherently bad about writing a windows service they just require more effort and an installer.
Based on your description a scheduled job seems to fit your requirements
If you don't want to re-write your console app into a windows service and want it to be running all the time, the only solution I could see is:
Create a small window's service, that checks to see if your console process is running or not.
If it finds that there is no Console process, then start a new one.
Process[] pname = Process.GetProcessesByName("YourConsoleApp.exe");
if (pname.Length == 0)
Process.Start("YourConsole.exe")
else
//Do nothing
I need to create an application that will run on a server and be able to be configured to run commands at certain times. For instance, there will be a web interface allowing a user to set an engage time and a disengage time. Once those values have been saved by the user I need for the server to be able to fire off those commands precisely at the time specified each day.
I would also need to be able to set single use non recurring events that would occur... maybe 10 minutes from the time an event was triggered and have a command fired off when that 10 minute timer goes off.
I've already got a class library written that has the engage and disengage commands exposed. I would hope to be able to integrate this into whatever solution I end up with and simply be able to make calls directly to the class. Alternatively I could also compile the class library into an executable and have commands issued to it via command line. I'm hoping to not have to do the latter.
I've never written anything like this before. I've peeked a bit at Windows Services, but there is a lot of chatter out there saying that it isn't necessarily the best option. Can someone please guide me in the right direction please?
A windows service is not a bad idea, its perfect for this kind of application. Unless you end up using standard windows scheduled tasks as the trigger for your command, you need some sort of process that is always running to contain your scheduler. A windows service is an excellent candidate for this.
Using a windows service in conjunction with Quartz.NET and some sort of persistence layer so you can store your schedules (in case you need to restart the service or it crashes etc) would be a good way to go.
Alternatively, you could write an application that just adds and removes windows scheduled tasks, but considering you have existing class libraries, using Quartz.NET will fit in well with your existing libraries.
easiest solution:
make a console exe and run under scheduled task in windows.
Let web page to accept user input and modify a configuration file.
I am looking to program a simple "data push" service, that extracts data out of a SQL Server database, and deposits a CSV file to a remote FTP site every ten minutes. This service will be running on a remote server, managed over TeamViewer.
There are a few ways I've thought to do this, but would like a bit of advice as to which is the best and most reliable method. A few pro's and cons would also be very helpful from people who have experience in this type of work.
Possible solutions:
Windows service with use of Thread.Sleep(..) to run task every ten minutes
Simple EXE console project that runs as a Windows Scheduler task
Windows service with use of a Timer class
Any other methods?
The program will be written in C#, but I am very flexible in terms of project type, design etc.
The main requirement of this service is to be reliable, and I'd also look to build in an alerts system to notify on failure.
Many thanks
I would favour a scheduled task for this kind of application, as it's far easier to make changes to the schedule at a later date.
There's a previous question along a similar line here: Windows Service or Task Scheduler for maintenance tasks?
Let me give a back ground for everybody before I go to my problem. My company hosts website for many clients, my company also contracts some of the work to another company.
So when we first set up a website with all the informations to our clients, we pass that information to the other company we contracted and three of us have the same data. Problem is once the site is up and running, our clients will change some data and when ever they do that we should be able to update our contracted company.
The way we transfer data to the contracted company is by using a web service (httppost, xml data). Now my question is what it the best way to write a program which sends updated data to the contracted company everytime our clients change some data.
1) Write a windows service having a timer inside my code where every 30min or so connects to the database and find all changes and send it to the contracted company
2) Write the same code as #1 (with out the timer in it) but this time make it a simple program and let windows scheduler wake it every 30min
3) Any other suggestion you may have
Techenologies available for me are VS 2008, SQLServer 2005
Scheduled task is the way to go. Jon wrote up a good summary of why services are not well suited for this sort of thing: http://weblogs.asp.net/jgalloway/archive/2005/10/24/428303.aspx
A service is easy to create and install and is more "professional" feeling so why not go that way? Using a non-service EXE would also work of course and would be slightly easier to get running (permissions, etc.) but I think the difference in setup between the two is nearly negligible.
One possible solution would be to add a timestamp column to your data tables.
Once this is done, you can have one entry in each table that has the last collected time by your contracted company. They can pull all records since that last time and update their records accordingly.
A Windows Service is more self contained, and you can easily configure it to start up automatically when the OS is starting up. You might also need to create additional configuration options, as well as some way to trigger the synchronization immediately.
It will also give you more room to grow your functionality for the service in the future.
A standalone app should be easier to develop though, however you are reliant on the windows scheduler to execute the task always. My experience has been that it is easier to mess up things with the windows scheduler and have it not run, for example in cases where you reboot the OS but no user has logged in.
If you want a more professional approach go with the service, even though it might mean a little bit more work.
A windows service makes more sense in this case. Think about what happens after your server is restarted:
With a Windows Application you need to have someone restart the application, or manually copy a shortcut to the startup folder to make sure the application gets launched
OR,
With a Windows Service you set it to start automatically and forget about it. When the machine reboots your service starts up and continues processing.
One more consideration, what happens when there is an error? A Windows application would likely show an error dialog and wait for input before continuing; whereas a service would log the error in the event log and carry on.