What kind of Application would be best for running non interactively?

Question

I need to create an application that can be activated with a batch file.

The application would accept a single string parameter of a file name. It will then run some processing with this file and drop another file in a predetermined location and exit.

The application does not need to interact with an actual user.

My preferred platform is .net using C#.

I originally planned on writing a console application but am not sure that this is the best idea.

What is the best way to accomplish this task? Is there a way to create a windows service that would be triggered by a batch file? Is this more desirable? Would a Windows Form project be more desirable?

Answer 1

If it's non-interactive, console is almost surely the way to go, as you could simply put it in the background and leave it alone.

Answer 2

Option one: Console App. Use Windows Scheduler to run it at schedule times. (recommended)

Option two: Windows Service that has some inbuilt scheduler or poller.

Answer 3

You could certainly create a Windows Service that watches for files to be placed into a particular folder. The batch file could then just put files into that folder.

I recommend you find a better reason to do this, though. Ask yourself, "in what way would this be better than a batch job just running a Console program and specifying the file name"?

Answer 4

The fastest thing to develop will likely be a console application, with a batch file, triggered by Windows Scheduled Tasks (or something similar).

This way, you only need to develop the the functionality of the application itself, rather than coming up with a scheduling framework.

You also get to take advantage of the functionality provided by Scheduled tasks, such as logging, easily customizable scheduling, error reporting etc. Another option to Windows Schdeduled tasks might be to use SQL Server Scheduled Jobs, that also provide a nice job history.

All that said, if you go down that path, you do have extra dependencies that you might be able to eliminate if you wrote your own Windows Service. In addition, if deployment is an issue, then writing a Windows Service with an installer gives you much greater control of the installation process.

Answer 5

A windows service with a FileSystemWatcher that watches the folder in question, instead of an always-on console app. That's what they're for, and if the system fails, you don't have to remember to put the file on, and you don't have to put it in your windows startup. Just set the service to start automatically.

Answer 6

My favorite option, and one which I convinced my previous employer to adopt as a company policy, is as follows:

All server-type applications are written with no directly-attached UI of any sort. Whether this compiles as a console application, as a windows application, or otherwise is irrelevant at the design stage -- with .NET the difference comes down to flipping a compiler switch. Generally, though, since the program is running without direct human intervention, we usually designed it to run as a service -- the Service Control Manager takes care of startup and shutdown, can restart the application when it fails, and does a lot of good stuff that is difficult to do on your own when writing a desktop application.

Next, you have the server application listen over the network for an "admin" to connect. This admin connection is your UI. Things like SSL encryption and authentication are up to you and your company, but at the base of it I would recommend building a line-based human-readable interface. That way you can connect to it with telnet and issue commands like "show connections", "drop user 52", and "restart". Any sort of administrative behavior, and any sort of status and statistics should be exposed using this interface. First of all, this helps with debugging, and second of all, it leads to the next step...

Last you build a UI. A simple one probably. Part of the configuration for this UI is to specify a host and port for it to connect to, as well as any authentication bits. The UI application connects to the machine running the service and issues commands over the network admin interface, and interprets the results. At our company, each new UI was a snap-in module as part of a larger project. This project would show little red and green lights representing the various servers and their statuses. Clicking on a server would allow you to "drill-down" to that server and examine various aspects of it state or configuration.

Though the project started as my little program on only one or two servers, it quickly grew to include dozens of servers running a handful of services each, running on diverse operating systems and in numerous cities around the world. This simple UI policy allowed us to easily track and control hundreds of these services from one single seat, or simultaneously at different desks in different offices.

Scalability mean not requiring someone in front of the computer to hit a button on a program you wrote.