We Keep Coding

what are the differences between having a .EXE file which is scheduled using Windows Task Scheduler and between having Windows service

I know that creating a Windows Service allow us to run background jobs without having to login to the machine. while .exe files can be run when users login to their PC and click on the .exe file (require user to be login).
But now let say i create a .exe file and i schedule it to run using windows Task Scheduler. where i can specify to run the task even when the user is not login.. so in this case what will be the real difference between :-
Having a .exe which is scheduled to run using task scheduler?
and between having a windows service ?
Thanks

Task Scheduler is generally suitable for processes which carry out periodic or occasional tasks, anything from once per minute, to "at logon" or "once per year". They can be made to effectively run continuously too, but that's really an abuse of the system.
Task Scheduler can also run processes in the context of the logged-on user, and such processes can interact with the user.
Services are generally suitable for processes which run continuously, such as those servicing devices, or providing network services.
Services generally cannot interact directly with the user. Where they need to do this, there is generally a user program which communicates with the service via some sort of RPC, such as DCOM, MSRPC or something else.
There isn't really anything a service can do which a program started by Task Scheduler cannot, or vice-versa: These capabilities depend on the login identity that the program runs under, not on how they are started.
Summary:
If you want a continuous process which provides services to the network, you probably want a service.
If the process is slow to start up, but cheap to keep going once running, you probably want a service.
If you want to perform periodic tasks of any kind, you probably want a scheduled task.
If the process is expensive or intensive in CPU or disk usage, you probably want to rewrite it so that it isn't.

As long as your software do whatever it has to do correctly, there will not be any differences. It all depends in what approach you want to give to your development. I usually try to involve the less components I can in this kind of solution just to make easier the troubleshooting and manteinance. For example If you install your .exe and configure it as a scheduled task, whenever it fails you will have to check not only what is inherent to your software but all what is involved in a scheduled task (user, schedules, triggers, services), and you not always will be able to control that, as your application may be installed on a server you do not have full rights to do what you want.
Also, take in consideration that every scheduled task depends on the Task Scheduler which is a service himself.
So to resume: The advanteges of creating a Job IMHO, is avoiding to recreate all the scheduled-triggered logic that might be a headache to develop if you have not done it before. And it is not better to reinvent the wheel. In the other hand, if you have some clear task that can be done with a Timer then it will probably be a better option just to create a Windows Service.

I would like to add here that windows service (schedule tasks) deployment is in developers hand. A developer can write a code to do change the process execution time at any point of time.
At other hand process run through "task scheduler " are dependent to the server admin. Developer has to guide the admin about what time scheduler must run. If there is any requirement to run the process at some irregular time, they have to approach to server admin, either to run the .EXE manually for now and also change the scheduler time. In other case admin only need to restart the service, he will not have any concern about the time!!!

Asp.Net web application database autoUpdate functionality

I created a functionality to update my web application database using data from an xml file. I want this database to be updated after ever 24hrs. My problem is I do not know where and how in the code should I call this method such that it does not have to be triggered by a button click and its executes after every 24hrs.
Please Help.

Part of the problem with background tasks in ASP.NET is that you don't have a standard application running to kick off your threads.
If you start firing off background tasks in the webapp, you can end up with inconsistent behaviour if something causes your appdomain to fail, your task can be stopped part-way, which if you're updating a DB could be a serious issue.
The most flexible way to implement this is using a seperate application running on a windows scheduled task which updates the DB for you. This separates the task from the webapp completely, but can be awkward to maintain.
It does however mean that even if your webapp is offline for whatever reason, the DB is still updated so long as the server running the task is working at the time.
If you do wish to embed the task in the webapp, something akin to cron would be preferable, as it will allow you to fire the task according to a set of rules, and leave it to its own devices.
Quartz Scheduler can achieve this, but can be fiddly to get working, and is sometimes overkill for simple tasks. It is worth learning for more involved systems which require a lot of tasks running in complex schedules, and allows the use of cron expressions.
HangFire is a different solution to the same problem, and is somewhat more simple than Quartz Scheduler, while still allowing cron configuration for tasks.
Using HangFire, the following will trigger the task at midnight every day (where UpdateDB is the method which runs the update).
RecurringJob.AddOrUpdate(() => UpdateDB(), "0 0 0 * * ?");
For your needs, HangFire is probably the quickest way to get this working.
The following will give you an overview of HangFire : http://docs.hangfire.io/en/latest/quick-start.html
HangFire is available in the NuGet archive so you can add it very quickly using the NuGet packages context menu, and documentation for timed tasks is here : http://docs.hangfire.io/en/latest/background-methods/performing-recurrent-tasks.html
Hopefully this is enough to get you started.

Run a scheduled process every day at a certain time on web service

I've been building a web service to synchronize data between SalesForce and Zendesk at my company. In the process of doing so, I've built several optimizations to drastically reduce execution time, such as caching some of the larger datasets that are retrieved from each service.
However, this comes at a price. When caching the data, it can upwards to 3-5 minutes to download everything through SalesForce and Zendesk's APIs.
To combat this, I was thinking of having a background worker that automatically cached all the required data every day a midnight. However, I'm not sure what the best method of doing this would be.
Would it suffice to build a class that merely has a worker thread that checks every several minutes to see if it is after midnight, and activate it on launch from Global.asax. Or is there some sort of scheduler already in existence?
EDIT
There seems to be some division between using something like:
FluentScheduler or Quartz.net to house everything within my applications.
Versus using something like windows task scheduler and writing a secondary application to call a function of my application to do so. It seems that using a third party library would be more simple, but is there any inherent benefit to using the Windows Task Scheduler.

I think you want to add your data caching logic to a project of type "console application". You'll be able to deploy this to your server and run it as a scheduled task using windows "Task Scheduler". If you've not worked with this project type or scheduled tasks before there are stack overflow questions which should help here, here, and here. You can add command line parameters if you need and you should have a look at adding a mutex so that only one instance of your code will ever run at once.

add an endpoint that will know how do it and use the windows task scheduler to call that new caching endpoint.

Custom Command Windows Services on HIGH Priority

I have an Work Tracker WPF application which deployed in Windows Server 2008 and this Tracker application is communicating with (Tracker)windows service VIA WCF Service.
User can create any work entry/edit/add/delete/Cancel any work entry from Worker Tracker GUI application. Internally it will send a request to the Windows service. Windows Service will get the work request and process it in multithreading. Each workrequest entry will actually create n number of work files (based on work priority) in a output folder location.
So each work request will take to complete the work addition process.
Now my question is If I cancel the currently creating work entry. I want to to stop the current windows service work in RUNTIME. The current thread which is creating output files for the work should get STOPPED. All the thread should killed. All the thread resources should get removed once the user requested for CANCEL.
My workaround:
I use Windows Service On Custom Command method to send custom values to the windows service on runtime. What I am achieving here is it is processing the current work or current thread (ie creating output files for the work item recieved).and then it is coming to custom command for cancelling the request.
Is there any way so that the Work item request should get stopped once we get the custom command.
Any work around is much appreciated.

Summary
You are essentially talking about running a task host for long running tasks, and being able to cancel those tasks. Your specific question seems to want to know the best way to implement this in .NET. Your architecture is good, although you are brave to roll your own rather than using existing frameworks, and you haven't mentioned scaling your architecture later.
My preference is for using the TPL Task object. It supports cancellation, and is easy to poll for progress, etc. You can only use this in .NET 4 onwards.
It is hard to provide code without basically designing a whole job hosting engine for you and knowing your .NET version. I have described the steps in detail below, with references to example code.
Your approach of using the Windows Service OnCustomCommand is fine, you could also use a messaging service (see below) if you have that option for client-service comms. This would be more appropriate for a scenario where you have many clients talking to a central job service, and the job service is not on the same machine as the client.
Running and cancelling tasks on threads
Before we look at your exact context, it would be good to review MSDN - Asynchronous Programming Patterns. There are three main .NET patterns to run and cancel jobs on threads, and I list them in order of preference for use:
TAP: Task-based Asynchronous Pattern
Based on Task, which has been available only since .NET 4
The prefered way to run and control any thread-based activity from .NET 4 onwards
Much simpler to implement that EAP
EAP: Event-based Asynchronous Pattern
Your only option if you don't have .NET 4 or later.
Hard to implement, but once you have understood it you can roll it out and it is very reliable to use
APM: Asynchronous Programming Model
No longer relevant unless you maintain legacy code or use old APIs.
Even with .NET 1.1 you can implement a version of EAP, so I will not cover this as you say you are implementing your own solution
The architecture
Imagine this like a REST based service.
The client submits a job, and gets returned an identifier for the job
A job engine then picks up the job when it is ready, and starts running it
If the client doesn't want the job any more, then they delete the job, using it's identifier
This way the client is completely isolated from the workings of the job engine, and the job engine can be improved over time.
The job engine
The approach is as follows:
For a submitted task, generate a universal identifier (UID) so that you can:
Identify a running task
Poll for results
Cancel the task if required
return that UID to the client
queue the job using that identifier
when you have resources
run the job by creating a Task
store the Task in a dictionary against the UID as a key
When the client wants results, they send the request with the UID and you return progress by checking against the Task that you retrieve from the dictionary. If the task is complete they can then send a request for the completed data, or in your case just go and read the completed files.
When they want to cancel they send the request with the UID, and you cancel the Task by finding it in the dictionary and telling it to cancel.
Cancelling inside a job
Inside your code you will need to regularly check your cancellation token to see if you should stop running code (see How do I abort/cancel TPL Tasks? if you are using the TAP pattern, or Albahari if you are using EAP). At that point you will exit your job processing, and your code, if designed well, should dispose of IDiposables where required, remove big strings from memory etc.
The basic premise of cancellation is that you check your cancellation token:
After a block of work that takes a long time (e.g. a call to an external API)
Inside a loop (for, foreach, do or while) that you control, you check on each iteration
Within a long block of sequential code, that might take "some time", you insert points to check on a regular basis
You need to define how quickly you need to react to a cancellation - for a windows service it should be within milliseconds, preferably, to make sure that windows doesn't have problems restarting or stopping the service.
Some people do this whole process with threads, and by terminating the thread - this is ugly and not recommended any more.
Reliability
You need to ask: what happens if your server restarts, the windows service crashes, or any other exception happens causing you to lose incomplete jobs? In this case you may want a queue architecture that is reliable in order to be able to restart jobs, or rebuild the queue of jobs you haven't started yet.
If you don't want to scale, this is simple - use a local database that the windows service stored job information in.
On submission of a job, record its details in the database
When you start a job, record that against the job record in the database
When the client collects the job, mark it for delayed garbage collection in the database, and then delete it after a set amount of time (1 hour, 1 day ...)
If your service restarts and there are "in progress jobs" then requeue them and then start your job engine again.
If you do want to scale, or your clients are on many computers, and you have a job engine "farm" of 1 or more servers, then look at using a message queue instead of directly communicating using OnCustomCommand.
Message Queues have multiple benefits. They will allow you to reliably submit jobs to a central queue that many workers can then pick up and process, and to decouple your clients and servers so you can scale out your job running services. They are used to ensure jobs are reliably submitted and processed in a highly decoupled fashion, and this can work locally or globally, but always reliably, you can even then combine it with running your windows service on cloud workers which you can dynamically scale.
Examples of technologies are MSMQ (if you want to maintain your own, or must stay inside your own firewall), or Windows Azure Service Bus (WASB) - which is cheap, and already done for you. In either case you will want to use Patterns and Best Practices for Enterprise Integration. In the case of WASB then there are many (MSDN), many (MSDN samples for BrokeredMessaging etc.), many (new Task-based API) developer resources, and NuGet packages for you to use

Ways to perform scheduled tasks - Windows / .NET

My issue is pretty simple.
I have an application that should be executed automatically once a day. I have no prior experience with this kind of scenario (some time ago I worked with IBM Control-M but guess that it is way more complete, complex and expensive =))
I thought about two possible solutions:
Creating a Task inside Windows Task Scheduler, which would execute the application;
Implement the application as a Window Service which would run 24/7, but only would perform the needed actions depending on the current time.
Which are the advantages/disadvantages of each approach?
Is there another way to do this?
Thanks in advance.

If it only executes once a day (or so) then just do it as a regular command line app that is executed by the windows task scheduler. Task scheduler already has all of the UI necessary to determine when to kick off the program, pass in parameters and anything else related to the scheduling of the task.
The only real reason to do this type of function as a windows service is if it needs higher execution resolution than once a minute. However, the main downside to a windows service is that you would have to manage the logic for how often/when to kick it off. Another one is that the app is always running, which leaves open the possibility for leaked memory if your code has issues.

On Unix/Linux you would use a cron job schedule a task to be executed. MS Windows' version is called the Task Scheduler and it is already a service that run 24/7 and performs the needed actions depending on the time.
Create a repeating task with the Task Scheduler to run your application. Creating, installing and configuring a service application is not exactly trivial. It's a much more involved process than creating a standard Forms or command line app and you don't need to do it anyway.

http://msdn.microsoft.com/en-us/magazine/cc164015.aspx
http://www.dotnetmonster.com/Uwe/Forum.aspx/dotnet-csharp/70633/Waitable-Timer-in-C

Another library that might be of interest is Quartz.NET