How To Convert A Console Application To A Windows Service?

Problem

Today I want to share how to easily convert an existing console application to a windows service. There are a few reasons why we would want to do that:

1. Console application must be running all time with an active user session in a server. A long running service application should be run by a non interactive (user logon) service account.
2. When the console application is crashed due to unhandled exception, stack overflow or whatever reason, it will not be able to start back automatically unless someone manually go and restart the application.
3. It is possible that someone login to the server with the same current active user session and accidentally close the console application.
4. When the server is rebooted unintentionally such as power trip, the console application cannot start automatically. (Unless configured using startup link).

Solution

I came across a MSDN magazine, and found out that people are talking about Topshelf. It is quite an interesting small framework that allow us writing a console application and then easily convert it into a windows service. This framework is independent and not relying on any other framework or component. Fore more info, visit HERE for their official site. This framework is obtainable from NuGet.

Well, let's start coding. First, create a new console application project in your Visual Studio, or if you intend to convert an existing console application into a windows service, then open existing project.

At your console application project, download the Topshelf component from NuGet.

Then, create a new class that implement ServiceControl interface from Topshelf like below. For existing console application, move all your code from the Program class to this new class. The ServiceControl interface only has 2 methods that need to be implemented. One is Start() is for code execution when the windows service is started, then Stop() for the stop.

public class FileProcessorService : ServiceControl

{

    private static FileProcessorComponent _component;

    public bool Start(HostControl hostControl)

    {

        try

        {

            //Execute my existing console application code

            _component = new FileProcessorComponent();

            _component.Start();

            return true;

        }

        catch

        {

            return false;

        }

    }

    public bool Stop(HostControl hostControl)

    {

        try

        {

            _component.Stop();

            return true;

        }

        catch

        {

            return false;

        }

    }

}

Then, at your console Program.cs Main method, create the Topshelf host that run the above service which implement the ServiceHost class like the following:

class Program

{

    static void Main(string[] args)

    {

        HostFactory.Run(host =>

        {

            host.SetServiceName("PuttyCatFileProcessor"); //cannot contain spaces or / or \

            host.SetDisplayName("Putty Cat File Processor");

            host.SetDescription("A file processor service that uses Topshelf.");

            host.StartAutomatically();

            //host.RunAs("service account name", "the password");

            //Don't think you like to expose your password in the code. =P

            //We can set it manually for one time after installing the windows service in the services.msc

               

            host.Service<FileProcessorService>();

        });

    }

}

In my host configuration, I used 4 methods that I find commonly we would use.

SetServiceName() - To set the service name, not the one display in the services.msc
SetDisplayName() - The display name that will appear in the services.msc list.
SetDescription() - The service description that will appear in services.msc and Task Manager.
StartAutomatically() - To indicate the service shall start automatically after reboot.
RunAs() - We can set the username and password which to be used to run this windows service. Though, I think no one would want to do that to expose your credential information in the code.

Now, to test your application, you can simply press F5 to proceed for debug. Even with the above code, it is NOT automatically install and run as windows service yet. It is still a console application.

This is how it look like after pressing F5:

Pros

1. Debug

So, here is one advantage that I quickly can identify is, Topshelf creates the convenience in debugging a windows service. In conventional way, we have to install windows service first with installutil.exe and then start it then from Visual Studio attach process to the windows service to debug. Sometimes, we think of workaround such as writing code to change the windows service's ServiceBase behavior to temporary run the code in console mode, so that we can simply debug windows service by just pressing F5.

2. Deployment

Another advantage is Topshelf internally already support accepting pre-defined parameters that automate the windows service install or uninstall. For example, to install your console application as a windows service, just run your console application with install parameter in a command prompt.

<Console App Name>.exe install

Note that the above verbose log during the windows service installation. It also cater for the event log registration which I suppose any error occur in the event log will be automatically logged in the application event log.

Then, you can verify your windows service installation. The display name, description, account, start mode were as defined in the code.

Here is where you set the service account information instead of entering credential information in the code which I mentioned just now.

And, here is the auto recovery that I mentioned just now that a console application cannot support.

Alright now, in order to uninstall your windows service, just run the same console application with uninstall parameter.

<Console App Name>.exe uninstall

3. Migration

Last advantage that I discover is I can easily migrate my existing console application into a windows service with very minimal code change. I can simply move the code from the Program class to another new class, then add a windows service host class on top of the new class to convert it into a windows services.

Cons

1. Redundant

Well, if you have experience with windows service development, actually you may find that windows service project template from Visual Studio is quite complete and generated all the basic necessary code already. It can achieve the same result as this little framework do. Somehow, I feel it is redundant.

2. Maintenance

As per this document, Topshelf prerequisites .net framework is version 4.0. Well, console project that uses later .net framework library may not be supported and used with Topshelf. Also, the project .net framework upgrade become dependent on Topshelf .net framework usage.

Summary

A long running console application should be running as a windows service for those stated reasons at the problem section above. Topshelf makes developer life easier in developing windows service by simplifying and automating the debug and deployment work. If you are interested with my complete source code, feel free to download it from HERE.