Develop Reference

Communication between service and application And also to trigger the application with GUI

I have developed an application which does periodical jobs. It runs as windows service in background and manages jobs. I want to trigger another application with GUI from service application when any error notification needs to be given to user. So after seeing err message user will give some response. So now service application (running as service) should do some work based on user response in GUI application (with interface). User response should be communicated to the service application.
So my requirement is
Application running as service should be able to trigger another application with GUI (its sufficient if triggering happens only when users are logged in)
Communication between an application running as service and application with GUI.
I saw many links about communication between service and application. Named pipes requires .net 3.5 and above, but I want my application to work in .net 2 alone. Writing to a txt file and reading it is last option for me as it is not the best method.
So how it can be done? Please give me ideas to start with.

File System watcher in Windows Service or Console Application?

I am implementing a file system watcher, my requirement is to watch for a given local folder on a machine and then do a small task (for example open a certain page in web browser). The file(s) in the given directory would be generated randomly sometimes every two hours or four etc. This tool should be automated in the sense that a user does not have to start it. So my question is, Should I implement this in a windows service which always will be running or in a console application.Preference is to do it in a console application but then it would need to started by a user right? Please advice

You can automatically call any type of application (Console, Windows, etc.). What it gets down to with a Windows Service is whether you want it to be running before anyone logs in.
Only a Windows service runs while no one is logged in. A console application (while it can be set to run on login) must have someone log in in order to run.

Is it good to have windows service or console application?

I have a tasks table in my db. I want to read data from this table and run tasks. Which one is better whether to have it as windows service or a console application running. The server on which this will be run will not be shutdown

You most likely want to use a windows service.
Benefits:
You can control the user (and the rights associated with this user account) which starts the process
An automatically started process means the desktop need to be on, not user logged, for the service to run
A policy on failure can be defined (try to restart n times run a specific program if fails)
A dependency can be defined (if you depend on other sevices)
You can wrap your script in an invisible window
You can easily start/stop/restart the script (net start <scriptname>)
Quoted from here: What is the benefit of developing the application as a windows service?

A running console app is not an option, as the others have stated.
If you just want the task run every x minutes the simplest option is a scheduled task using a console application.
A windows service has it's benefits, but is a little bit more complex to implement and deploy. However if your app needs to be 'always on' (e.g. need to react to external triggers, listen to message queue, ...), a windows service is the only option. As the others have said, the services infrastructure also provides more management capabilities, built-in integration with the event log, restart and failover options...

Windows service, because it does not require logged-in user.

I would say; Windows Services.
In that case (among other things) you don't need a user to be logged in, you can configure it in a matter to restart automatically if it shuts down for some reason and you (could) have extensive rights throughout the system.

Windows service generally. Console app will need to be restarted if the server reboots while a windows service can start automatically.

You should look at: https://github.com/thedavejay/Self-Installing-Windows-Service
It allows you to debug as a console application and then install it as a windows service.

How to create a Windows Service through another Windows Service

I'm having a bit of trouble with an application i'm developing.
Here's the scenario: I have two Windows Services (Service A and Service B) written in C#.
Service A is responsible to transfer data between two applications (using WebServices, FTP connections, etc). It's also responsible to update Service B.
Service B is responsible to update Service A and update a Web Application.
The basic operation of updates is (lets say this is the process to update service A, done by Service B):
Check for updates through WebServices
If there is a new version, stop the service (using C# ServiceController).
Backup current files of the service (so I can do a Rollback if something goes wrong)
Uninstall the service (using sc delete command)
Download the updated files of the service (using FTP connection)
Execute some SQL Server scripts, if exist
Install the Windows Service (using sc create command)
Start Service (using C# ServiceController)
Everything runs smoothly until step 7. I figured that the problem is that the user doing the update (the user that runs Service B) does not have permissions to create new windows services, so SC Create always returns something like "[SC] OpenSCManager FAILED 5: Access is denied"
Note that I had both services running with LocalSystem Account. So, I figured that this account cannot create new Windows Services (correct me if I've assumed wrong).
After this I've created a new Windows User, just to run the services. The idea was to give this user the necessary permissions (to network shared, files and create services). However, this user still can't create the service.
Here's what I've tried:
Give the user cmd.exe and sc.exe permissions (using CACLS).
Use PsExec to run cmd (with -i -s) instead of cmd.exe directly.
Using the SubInAcl command so the user has permissions to the both Windows Service. But here's the thing, at the time I don't have any Service, so it doesn't work.
Some remarkes:
This Windows Services don't have any installer.
The SC command is run using C# ProcessStartInfo.
The SC command specifies the user and password of the Windows User that I've created.
I really don't want the Windows Services to be run under a user account with Administrative Privileges.
I know that this thread is similar to some already here Auto-update a Windows Service, however I cannot find any working solution anywhere.
Sorry for the long text

I think your basic design is brittle and flawed. You should not be deleting and creating services as part of normal service operation.
What I would do would be to arrange that any service that needs updating in place was capable of doing it by itself. Basically put all the code that is subject to update in a DLL. The code in the service EXE is just a thin host in charge of loading the main DLL and invoking it's main processing loop. When the EXE determines that it is time to update it downloads the new DLL, presumably checking via a hash that it downloaded correctly. Next the processing loop is terminated, the old DLL is unloaded, the new DLL is loaded and the processing loop started again.
This approach is much less intrusive and avoids all permission and rights issues. You can write a single service host EXE and have multiple DLLs containing the logic.

How to keep a process running on a remote windows server

I need to implement a background process that runs on a remote windows server 24/7. My development environment is C#/ASP.NET 3.5. The purpose of the process is to:
Send reminder e-mails to employees and customers at appropriate times (say 5:00PM on the day before a job is scheduled)
Query and save GPS coordinates of employees when they are supposed to be out on jobs so that I can later verify that their positions were where they were supposed to be.
If the process fails (which it probably will, especially when updates are added), I need for it to be restarted immediately (or within just a few minutes) as I would have very serious problems if this process failed to send a notification, log a GPS coordinate, or any of the other tasks its meant to perform.

Implement your process as a Windows service.
For a straightforward example of how
to code a Windows service this in
.Net see http://www.developer.com/net/csharp/article.php/2173801 .
To control what happens should the
service fail configure this through
the "Recovery" tab on your service
in services.msc. (see image below)
For higly critical operation you
might look into setting up a server cluster for mitigating single
server failure (see http://msdn.microsoft.com/en-us/library/ms952401.aspx ).
(source: microsoft.com)

You need a Windows Service. You can do non-visual iterative operations in windows services.

Another alternative is to create a normal application and run it on a schedule. Your application is run at certain times a day to perform its actions, depending on how often you need to log GPS coordinates and send reports. If your service doesn't need to run constantly this is usually the recommended approach, as services are supposed to be limited to always-on applications.

As well as being a service, you might want to run on a cluster, and make your service known to the cluster management software.

You can create Windows Service (server programming on Windows) or use scheduler to periodically execute a task.
Depending on the requirements for the high availability, program can be installed on a fail-over cluster where there will be other server (passive node) started and quietly waiting as a hot-backup if the first (active node) dies. This is wide topic. Start with High availablity on Wikipedia.

In my experience if you need to run something 24x7 you need to have (one or more) watchdog process to verify that your service(s) are running correctly. Just relying on the normal service framework cannot guarantee that the program is working correctly - even if it looks like it is running. The watchdog program (which also is a service) can query the service automatically e.g. posting messages checking response times, querying for statistics and so on - when it detects problems it can restart the service (or do some other fail-recovery)
The reason for having a watchdog program as opposed to just rely on user queries to detect errors is that it can be done automatically. This is the preferred method because it allows for a proactive detection.