I've been working quite a bit with Windows Services in
the recent months, and well, it turns out that Windows Services are quite a bear to debug, deploy, update and maintain.
The process of getting services set up, debugged and updated is a major chore that has to be extensively documented and or automated specifically. On most projects when a service is built, people end up scrambling for
the right 'process' to use for administration. Web app deployment and maintenance on
the other hand are common and well understood today, as we are constantly dealing with Web apps. There's plenty of infrastructure and tooling built into Web Tools like Visual Studio to facilitate
the process. By comparison Windows Services or anything self-hosted for that matter seems convoluted.In fact, in a recent blog post I mentioned that on a recent project I'd been using self-hosting for SignalR inside of a Windows service, because
the application is in fact a 'service' that also needs to send out lots of messages via SignalR. But
the reality is that it could just as well be an IIS application with a service component that runs in
the background. Either way you look at it, it's either a Windows Service with a built in Web Server, or an IIS application running a Service application, neither of which follows
the standard Service or Web App template.Personally I much prefer Web applications. Running inside of IIS I get all
the benefits of
the IIS platform including service lifetime management (crash and restart), controlled shutdowns,
the whole security infrastructure including easy certificate support, hot-swapping of code and
the the ability to publish directly to IIS from within Visual Studio with ease.Because of these benefits we set out to move from
the self hosted service into an ASP.NET Web app instead.
The Missing Link for ASP.NET as a Service: Auto-LoadingI've had moments in
the past where I wanted to run a 'service like' application in ASP.NET because when you think about it, it's so much easier to control a Web application remotely. Services are locked into start/stop operations, but if you host inside of a Web app you can write your own ticket and control it from anywhere. In fact nearly 10 years ago I built a background scheduling application that ran inside of ASP.NET and it worked great and it's still running doing its job today.
The tricky part for running an app as a service inside of IIS then and now, is how to get IIS and ASP.NET launched so your 'service' stays alive even after an Application Pool reset. 7 years ago I faked it by using a web monitor (my own West Wind Web Monitor app) I was running anyway to monitor my various web sites for uptime, and having
the monitor ping my 'service' every 20 seconds to effectively keep ASP.NET alive or fire it back up after a reload. I used a simple scheduler class that also includes some logic for 'self-reloading'. Hacky for sure, but it worked reliably.Luckily today it's much easier and more integrated to get IIS to launch ASP.NET as soon as an Application Pool is started by using
the Application Initialization Module.
The Application Initialization Module basically allows you to turn on Preloading on
the Application Pool and
the Site/IIS App, which essentially fires a request through
the IIS pipeline as soon as
the Application Pool has been launched. This means that effectively your ASP.NET app becomes active immediately, Application_Start is fired making sure your app stays up and running at all times. All
the other features like Application Pool recycling and auto-shutdown after idle time still work, but IIS will then always immediately re-launch
the application.Getting started with Application InitializationAs of IIS 8 Application Initialization is part of
the IIS feature set. For IIS 7 and 7.5 there's a separate download available via Web Platform Installer. Using IIS 8 Application Initialization is an optional install component in Windows or
the Windows Server Role Manager:
This is an optional component so make sure you explicitly select it.IIS Configuration for Application InitializationInitialization needs to be applied on
the Application Pool as well as
the IIS Application level. As of IIS 8 these settings can be made through
the IIS Administration console.Start with
the Application Pool:Here you need to set both
the Start Automatically which is always set, and
the StartMode which should be set to AlwaysRunning. Both have to be set -
the Start Automatically flag is set true by default and controls
the starting of
the application pool itself while Always Running flag is required in order to launch
the application. Without
the latter flag set
the site settings have no effect.Now on
the Site/Application level you can specify whether
the site should pre load:
Set
the Preload Enabled flag to true.At this point ASP.NET apps should auto-load. This is all that's needed to pre-load
the site if all you want is to get your site launched automatically.If you want a little more control over
the load process you can add a few more settings to your web.config file that allow you to show a static page while
the App is starting up. This can be useful if startup is really slow, so rather than displaying blank screen while
the user is fiddling their thumbs you can display a static HTML page instead: <system.webServer>
<applicationInitialization remapManagedRequestsTo="Startup.htm"
skipManagedModules="true">
<add initializationPage="ping.ashx" />
</applicationInitialization>
</system.webServer>This allows you to specify a page to execute in a dry run. IIS basically fakes request and pushes it directly into
the IIS pipeline without hitting
the network. You specify a page and IIS will fake a request to that page in this case ping.ashx which just returns a simple OK string - ie. a fast pipeline request. This request is run immediately after Application Pool restart, and while this request is running and your app is warming up, IIS can display an alternate static page - Startup.htm above. So instead of showing users an empty loading page when clicking a link on your site you can optionally show some sort of static status page that says, "we'll be right back". I'm not sure if that's such a brilliant idea since this can be pretty disruptive in some cases. Personally I think I prefer letting people wait, but at least get
the response they were supposed to get back rather than a random page. But it's there if you need it.Note that
the web.config stuff is optional. If you don't provide it IIS hits
the default site link (/) and even if there's no matching request at
the end of that request it'll still fire
the request through
the IIS pipeline. Ideally though you want to make sure that an ASP.NET endpoint is hit either with your default page, or by specify
the initializationPage to ensure ASP.NET actually gets hit since it's possible for IIS fire unmanaged requests only for static pages (depending how your pipeline is configured).What about AppDomain Restarts?In addition to full Worker Process recycles at
the IIS level, ASP.NET also has to deal with AppDomain shutdowns which can occur for a variety of reasons:Files are updated in
the BIN folderWeb Deploy to your siteweb.config is changedHard application crashThese operations don't cause
the worker process to restart, but they do cause ASP.NET to unload
the current AppDomain and start up a new one. Because
the features above only apply to Application Pool restarts, AppDomain restarts could also cause your 'ASP.NET service' to stop processing in
the background.In order to keep
the app running on AppDomain recycles, you can resort to a simple ping in
the Application_End event:protected void Application_End()
{
var client = new WebClient();
var url = App.AdminConfiguration.MonitorHostUrl + "ping.aspx";
client.DownloadString(url);
Trace.WriteLine("Application Shut Down Ping: " + url);
}which fires any ASP.NET url to
the current site at
the very end of
the pipeline shutdown which in turn ensures that
the site immediately starts back up.Manual Configuration in ApplicationHost.configThe above UI corresponds to
the following ApplicationHost.config settings. If you're using IIS 7, there's no UI for these flags so you'll have to manually edit them.When you install
the Application Initialization component into IIS it should auto-configure
the module into ApplicationHost.config. Unfortunately for me, with Mr. Murphy in his best form for me,
the module registration did not occur and I had to manually add it.<globalModules>
<add name="ApplicationInitializationModule"
image="%windir%\System32\inetsrv\warmup.dll" />
</globalModules>Most likely you won't need
ever need to add this, but if things are not working it's worth to check if
the module is actually registered.Next you need to configure
the ApplicationPool and
the Web site.
The following are
the two relevant entries in ApplicationHost.config.<system.applicationHost>
<applicationPools>
<add name="West Wind West Wind Web Connection"
autoStart="true"
startMode="AlwaysRunning"
managedRuntimeVersion="v4.0"
managedPipelineMode="Integrated">
<processModel identityType="LocalSystem"
setProfileEnvironment="true" />
</add>
</applicationPools>
<sites>
<site name="Default Web Site" id="1">
<application path="/MPress.Workflow.WebQueueMessageManager"
applicationPool="West Wind West Wind Web Connection"
preloadEnabled="true">
<virtualDirectory path="/"
physicalPath="C:\Clients\…" />
</application>
</site>
</sites>
</system.applicationHost>On
the Application Pool make sure to set
the autoStart and startMode flags to true and AlwaysRunning respectively. On
the site make sure to set
the preloadEnabled flag to true.And that's all you should need. You can still set
the web.config settings described above as well.ASP.NET as a Service?In
the particular application I'm working on currently, we have a queue manager that runs as standalone service that polls a database queue and picks out jobs and processes them on several threads.
The service can spin up any number of threads and keep these threads alive in
the background while IIS is running doing its own thing. These threads are newly created threads, so they sit completely outside of
the IIS thread pool. In order for this service to work all it needs is a long running reference that keeps it alive for
the life time of
the application.In this particular app there are two components that run in
the background on their own threads: A scheduler that runs various scheduled tasks and handles things like picking up emails to send out outside of IIS's scope and
the QueueManager. Here's what this looks like in global.asax:public class Global : System.Web.HttpApplication
{
private static ApplicationScheduler scheduler;
private static ServiceLauncher launcher;
protected void Application_Start(object sender, EventArgs e)
{
// Pings
the service and ensures it stays alive
scheduler = new ApplicationScheduler()
{
CheckFrequency = 600000
};
scheduler.Start();
launcher = new ServiceLauncher();
launcher.Start();
// register so shutdown is controlled
HostingEnvironment.RegisterObject(launcher);
}}By keeping these objects around as static instances that are set only once on startup, they survive
the lifetime of
the application.
The code in these classes is essentially unchanged from
the Windows Service code except that I could remove
the various overrides required for
the Windows Service interface (OnStart,OnStop,OnResume etc.). Otherwise
the behavior and operation is very similar.In this application ASP.NET serves two purposes: It acts as
the host for SignalR and provides
the administration interface which allows remote management of
the 'service'. I can start and stop
the service remotely by shutting down
the ApplicationScheduler very easily. I can also very easily feed stats from
the queue out directly via a couple of Web requests or (as we do now) through
the SignalR service.Registering a Background Object with ASP.NETNotice also
the use of
the HostingEnvironment.RegisterObject(). This function registers an object with ASP.NET to let it know that it's a background task that should be notified if
the AppDomain shuts down. RegisterObject() requires an interface with a Stop() method that's fired and allows your code to respond to a shutdown request. Here's what
the IRegisteredObject::Stop() method looks like on
the launcher:public void Stop(bool immediate = false)
{
LogManager.Current.LogInfo("QueueManager Controller Stopped.");
Controller.StopProcessing();
Controller.Dispose();
Thread.Sleep(1500); // give background threads some time
HostingEnvironment.UnregisterObject(this);
}Implementing IRegisterObject should help with reliability on AppDomain shutdowns. Thanks to Justin Van Patten for pointing this out to me on Twitter.RegisterObject() is not required but I would highly recommend implementing it on whatever object controls your background processing to all clean shutdowns when
the AppDomain shuts down.Testing it outI'm still in
the testing phase with this particular service to see if there are any side effects. But so far it doesn't look like it. With about 50 lines of code I was able to replace
the Windows service startup to Web start up - everything else just worked as is. An honorable mention goes to SignalR 2.0's oWin hosting, because with
the new oWin based hosting no code changes at all were required, merely a couple of configuration file settings and an assembly directive needed, to point at
the SignalR startup class. Sweet!It also seems like SignalR is noticeably faster running inside of IIS compared to self-host. Startup feels faster because of
the preload.Starting and Stopping
the 'Service'Because
the application is running as a Web Server, it's easy to have a Web interface for starting and stopping
the services running inside of
the service. For our queue manager
the SignalR service and front monitoring app has a play and stop button for toggling
the queue.If you want more administrative control and have it work more like a Windows Service you can also stop
the application pool explicitly from
the command line which would be equivalent to stopping and restarting a service.To start and stop from
the command line you can use
the IIS appCmd tool. To stop:> %windir%\system32\inetsrv\appcmd stop apppool /apppool.name:"Weblog"and to start> %windir%\system32\inetsrv\appcmd start apppool /apppool.name:"Weblog"Note that when you explicitly force
the AppPool to stop running either in
the UI (on
the ApplicationPools page use Start/Stop) or via command line tools,
the application pool will not auto-restart immediately. You have to manually start it back up.What's not to like?There are certainly a lot of benefits to running a background service in IIS, but… ASP.NET applications do have more overhead in terms of memory footprint and startup time is a little slower, but generally for server applications this is not a big deal. If
the application is stable
the service should fire up and stay running indefinitely. A lot of times this kind of service interface can simply be attached to an existing Web application, or if scalability requires be offloaded to its own Web server.Easier to work withBut
the ultimate benefit here is that it's much easier to work with a Web app as opposed to a service. While developing I can simply turn off
the auto-launch features and launch
the service on demand through IIS simply by hitting a page on
the site. If I want to shut down an IISRESET -stop will shut down
the service easily enough. I can then attach a debugger anywhere I want and this works like any other ASP.NET application. Yes you end up on a background thread for debugging but Visual Studio handles that just fine and if you stay on a single thread this is no different than debugging any other code.SummaryUsing ASP.NET to run background service operations is probably not a super common scenario, but it probably should be something that is considered carefully when building services. Many applications have service like features and with
the auto-start functionality of
the Application Initialization module, it's easy to build this functionality into ASP.NET. Especially when combined with
the notification features of SignalR it becomes very, very easy to create rich services that can also communicate their status easily to
the outside world.Whether it's existing applications that need some background processing for scheduling related tasks, or whether you just create a separate site altogether just to host your service it's easy to do and you can leverage
the same tool chain you're already using for other Web projects. If you have lots of service projects it's worth considering… give it some thought…© Rick Strahl, West Wind Technologies, 2005-2013Posted in ASP.NET SignalR IIS
Tweet
!function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0];if(!d.getElementById(id)){js=d.createElement(s);js.id=id;js.src="//platform.twitter.com/widgets.js";fjs.parentNode.insertBefore(js,fjs);}}(document,"script","twitter-wjs");
(function() {
var po = document.createElement('script'); po.type = 'text/javascript'; po.async = true;
po.src = 'https://apis.google.com/js/plusone.js';
var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(po, s);
})();
