Thoughts on running Windows Service type apps on ASP .NET 4 with StartMode="AlwaysRunning"

Question

Usually I would look at writing a Windows Service to manage tasks that aren't suited to being hosted in a web application. These types of tasks are usually long running processes or scheduled tasks. Although this is normally the primary approach for these types of tasks, people have looked at ways of running these kinds of background processes in a web application by kicking off a number of threads in the Application_Start event exposed by Global.asax. The problem with this approach has always been that if your IIS worker process dies, then your background thread is killed too (effectively your 'Windows Service' is stopped until the next request is received).

ASP .NET 4.0 offers a solution to this problem. You can now set the StartMode to 'AlwaysRunning' as described in this blog post by Scott Gu. Somewhere in the comments on this post, someone asks a question about the viability of hosting Windows Service type tasks in IIS since the new feature ensures the worker process is always running. Scott mentioned that it would definitely support the scenario. Further to this, the recent introduction of AppFabric means that Microsoft themselves are providing simple hooks for hosting and monitoring WCF and WF services in a web application.

What does this mean for those of us that used to write Windows Services to support our web apps? Should we adopt this model? What are the pitfalls? As far as I can tell, there are a number of benefits to hosting 'Windows Service' processes in a web application, the most useful being the ease of deployment. Furthermore, we can actually start developing simple user interfaces to our services which provide information about what is happening at runtime.

If I had to go this route, I don't think that I would host my 'Windows Service' type functionality in the customer facing web application. I would probably develop a new web application project (much like I would in the Windows Service context) that would host my long running/scheduled task processes. I guess there are few reasons for this.

1. Security. There may be a different security model for the UI displaying information about the running background processes. I would not want to expose this UI to anyone else but the ops team. Also, the web application may run as a different user which has an elevated set of permissions.
2. Maintenance. It would be great to be able to deploy changes to the application hosting the background processes without impacting on user's using the front end website.
3. Performance. Having the application separated from the main site processing user requests means that background threads will not diminish IIS's capability to handle the incoming request queue. Furthermore, the application processing the background tasks could be deployed to a separate server if required.

I would be really interested to hear your thoughts on this approach and whether I should be sticking with Windows Services. I am very tempted to try this new approach.

Nicolette

Answer 1

What does this mean for those of us that used to write Windows Services to support our web apps?

I think this a key scenario where you could be move away from a Windows service to using the continous running web site.

Should we adopt this model?

Standard development answer: Depends ;)

What are the pitfalls?

One issue I can see is the IIS dependency. If you need a service to run on a users machine I would not feel comfortable about asking them to install IIS just to run my service. Here I think the traditional model works better.

Monitoring and tracking are major issues, but as you also point out this is solved by AppFabric. It is even better than what you get from the Window Service. However you have added another dependency which also will require .NET 4.0 and a relatively new version of Windows. I could also be wrong here, but my understanding is that AppFabric is not supported in production on client OS's. Which could bring in additional headaches.

You will lose pause functionality in the continuous web site model too.

Finally IIS killing inactive app-pools isn't the only way an app pool can recycle. Editing a web.config file causes it for instance, which may not be an ideal situation.

the most useful being the ease of deployment.

I also think development is much easier - in the past I have had a console app and a windows service so I can dev/test on my machine using the console app and then change it to a windows service when it goes out. Now dev/test is MUCH easier.

A must read for this is Death to Windows Services...Long Live AppFabric!

Chapfallen

Thanks for posting your thoughts. I agree, I wouldn't look at developing a service in a web app if the requirement is that it needs to be installed on a user's machine. Regarding Windows Service development, I don't mind the environment so I don't know if it is easier/better. You mentioned you start with a console app for a Windows Service - I wondered what the reason for this is? I usually create the service and replace the ServiceBase initialisation stuff with alternative code in debug mode. – Nicolette

For a Windows Service project I normally do the following. Create a empty solution, add a class library, add a console app and reference the class library and add a windows service and reference the class library. In the class library I do all the real work, and the console app and windows service end up just being a way to call it. This means that while in VS, I can set the console app to be the default project and just hit F5 to test and debug. When I am ready for more real production or testing I can then just build the service ad all works the same - mostly ;) – Chapfallen

Answer 2

What are the pitfalls?

One I found, no shutdown event. You have AppStart when the web site starts (not global.asax because that is HTTP only) but you have no way to handle shutdown which could mean disposing becomes an issue.

Chapfallen

This seems really hacky, but couldn't you get around this by firing a web request to your app in the AppStart.AppInitialize event? You Application_Start would fire in the Global.asax (start your background worker threads here), and you would get a shutdown event in the form of Application_End. I have successfully tested this by starting a background thread in the AppInitialize event that makes a web request to the web application. You could implement a handler for dealing with startup failure by checking the status code of the request and throw an exception if it failed. – Nicolette

Those would only work in HTTP scenarios. If you build a service which will take via tcp/ip (net.tcp) or named pipes (net.pipe) then those will not work as global.asax is only used in HTTP scenarios. – Chapfallen

It need not just be HTTP scenarios. For example, I could start a WorkflowApplicationManager in a separate thread launched from the Application_Start event. In the Application_End event I could signal a graceful shutdown. I don't need to utilise the HTTP binding to service any webrequests. That said, it would be useful to monitor the state of the background process by developing status endpoints (web pages). Note, I am thinking of running custom long running services/processes/tasks not necessarily utilising WF/WCF. – Nicolette

The only way I found to handle shutdown is to subscribe to AppDomain.Current.DomainUnload at the point when you construct whatever it is that needs to be disposed of – Holguin

Answer 3

I would suggest sticking with a windows service. The issue is with your number 2. You won't be able to update service part of web site without restarting whole web site.

Wellgrounded

Agreed. That is why I mentioned that I would develop it as a separate project. That way I could re-deploy the application without affecting users. – Nicolette

What you could do is have virtual directories, each with their own app-pool associated to them. In this case you could update the service part without the rest being effected because of the seperation of app-pools. – Chapfallen