Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I know variations of this topic have already been asked, but here's my situation:
I have about 30 FTP interface applications. Each interface has their own requirements and configuration, but basically it downloads files from a source server – sometimes daily, sometimes every minute (some, possibly even scheduled in the seconds)
For my initial development, I wrote a C# class library that does all FTP work. This application (be it a console app or windows service) will most likely be run under Windows Server 2012.
Now comes the next piece and I’m trying to decide between:
1) Writing a console app (or a powershell script?) that takes command
line inputs plus a configuration file for each interface. I would
schedule this using Windows Task Scheduler. For deployment of these
interfaces, I could create a batch file that uses the “schtasks.exe”
to create and configure the task. One task for each interface. Sounds
easy peasy…
OR
2) Write a windows services application… but here, I am confused. Do I
create and install a service for each one of my interfaces? (i.e. only
thing different might be the config file). Or, do I create a a main
service that spawns off threads for each interface defined in a single
config file?
If I did this as a single service, how do I manage the
maintenance/deployment of this? If I stop the service, would it not
affect all the interfaces? And how do I perform the actual
scheduling? I’ve read the suggestion is to use Quartz.Net scheduler or
just .Net Timers.
---
Some additional thoughts:
Here are some readings on StackOverflow which brings up these topics/concerns:
windows service vs scheduled task
Scheduled console app vs Windows service? When is it appropriate to use each
Task Scheduler Concerns
List item
May need to be logged in? (I’ve read this is not true)
Issues on machine admin password change (I’ve read this is not true)
Issues with running in high-authority accounts (NetworkService, LocalSystem, or a User)
Issue with multiple processes / long running transactions
This would be really bad for me, for example, if two processes tried to download (and delete) the same source FTP file.
Experience of many is that this is not as stable/reliable as Windows Services, especially on earlier operating systems pre Windows7
Less infrastructure support (e.g. failure policies for retry, monitoring, etc.)
Concerns when scheduling in the seconds…
Windows Service Concerns
List item
Potential issues with Timers
More complicated
Console App + Scheduled Task Concerns
List item
Can’t run in background – so hosting server will have command prompts launching
This is a serious problem. If I have 30 FTP Interfaces and each is scheduled to run every minute/hour, that’s a lot of windows!!!
How do I get around this? Use PowerShell scripts instead?
Looking forward to some feedback, and sample code/scripts, if relevant also highly appreciated.
Thanks
You can access your c# class in powershell using
Either add-type or [System.Reflection.Assembly] - check out this SO post for examples - Can I access My Custom .NET Class from PowerShell?
You could do it all in powershell, using start-job and the like, but then your controlling script will need a lot of effort.
I'd be tempted to use Powershell' inbuilt (in version 3) cmdlets for creating/modifying scheduled jobs in task scheduler and custom triggers - http://blogs.technet.com/b/heyscriptingguy/archive/2012/09/18/create-a-powershell-scheduled-job.aspx
Have it schedule jobs that are running .ps1 powershell scripts, one for each transfer or group of related transfers e.g. Monthly_Payroll_xfer.ps1, Weekly_Expenses_xfer.ps1 with logic relevant to that transfer, email alerts on success/failure etc.
The only thing that doesn't solve is same file/destination being processed at the same time but you could potentially have the individual scripts check at start if they are running already - see the accepted answer to this post - Assure only 1 instance of PowerShell Script is Running at any given Time
As for windows prompts, you can run a scheduled task as a user that won't be logged on, and you won't see the powershell command windows as they will be on a different console - be sure not to set -noexit switch of powershell.exe so they do go away when finished.
Had to do this at work for a tool that only runs as GUI, not as a service, and can't be frigged with srvany etc - we setup a scheduled task that runs (at startup) as a service account and runs a powershell script that runs the GUI.exe
We then use powershell scripts to stop-process to kill it, disable/enable the task (like disabling/enabling a service) and one to run the task.
It's a cludge but it works.
Apologies I haven't given much in the way of code examples, doing this on my phone but may give you ideas.
You can also do it all in c# - we have an in-house developed application with SQL back-end that does exactly what you're trying to achieve, very successfully, multi-threaded with very high volumes being chucked at it..
However, my employers' Intellectual Property and other policies prevent me sharing any more about it than that :-(
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.
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.”
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?