Hosting a SignalR application on Windows 2008r2 and IIS 7.5

ASP.NET SignalR is Microsoft's new library for adding real-time functionality to applications.   You can host ASP.NET applications with SignalR on Windows Server 2012 and IIS 8 (this setup provides full HTML 5 WebSocket API support for real-time functionality), or you can host on previous versions of Windows Server and IIS.  Previous server versions do not offer websockets support, instead they use fallback transport mechanisms such as forever frames, server-sent events, and Ajax long polling.  For more information, see SignalR Transports.  Because previous server versions use fallback transport mechanisms, hosting on a previous server platform requires a few extra steps to get your SignalR application working in all browsers. 

This posts pulls together several related steps that it takes to get a SignalR application working on a common previous-version hosting scenario:   Windows 2008r2 and IIS 7.5.  You can see a listing of these and other steps for working with SignalR applications on the SignalR Wiki FAQ page.  The application sample used to test the steps in this post is from the tutorial Getting Started with SignalR.  Instead of building the sample on .NET Framework 4.5 (as in the tutorial), I built it on .NET Framework 4, a common hosting scenario on IIS 7.5.

Here's a summary of the required setup steps to host on Windows 2008r2 with IIS 7.5:

1. Update the SignalR application's web.config file to enable "run all managed modules for all requests" (for short, this is the RAMMFAR setting). 
2. Update the web page that uses SignalR to communicate with the server:
   1. Add a reference to the json2.js library. 
   2. Add a <meta> tag that forces the content to display in a recent browser mode.
3. Set up a Windows Server 2008r2 with IIS 7.5 as follows:
   1. Install the .NET Framework version that your SignalR application requires.
   2. Create a site and associate it with the appropriate application pool. 

Update the Signalr Application's Web.config File

In your SignalR application's web.config file, add the RAMMFAR setting to enable running all managed modules for all requests. This setting was required to get the SignalR sample application running in on Windows 2008r2 and IIS 7.5 in all browsers. 

<system.webServer>
   <modules runAllManagedModulesForAllRequests="true">
   </modules>
</system.webServer> 

Update the Web Page that Uses SignalR

In the application web page that uses SignalR to communicate with the server, add the following code.

• Add a reference to the json2.js JSON parser library.  This script provides a JSON parser for previous browser versions that don't have it. You can add the script in one of two ways:
  • Add the NuGet package json2.js to your project, and then reference it in your web page:   

<script src="scripts/json2.js"></script>

• • Or as an alternative, reference json2.js on a CDN:  

<script src="https://cdnjs.cloudflare.com/ajax/libs/json2/20121008/json2.js"></script>

• Add the following <meta> tag in the head section of the page.  This tag, specifically the IE=edge value,  forces Internet Explorer to display content in the most recent version available, rather than earlier modes (such as IE7) which prevent SignalR code from working.

<meta http-equiv="X-UA-Compatible" content="IE=edge" />

Set up Windows Server 2008r2 and IIS 7.5

 As noted, I built the sample SignalR application from the Getting Started with SignalR tutorial on .NET 4.  This is a common hosting scenario on Windows 2008r2 and IIS 7.5.   The server was a new default default installation of Windows Server 2008r2 and IIS 7.5.

• Install the required .NET Framework version.  In this case I installed .NET Framework 4.
• Create a new site in IIS Manager, and associate the site with an application pool.  Use integrated mode application pools, classic mode is not supported for SignalR.  For this application I used the ASP.NET v4.0 application pool. 

After following the above setup steps, I was able to deploy the .NET Framework 4-based version of the Getting Started with SignalR sample to the server, and it worked perfectly in IE (versions 8, 9, and 10), Chrome, and Firefox even though it was using fallback transport methods (forever frames in IE, and server-sent events in the other browsers).   The interesting thing for SignalR developers is that apart from the above steps, I didn't have to change a single line of the SignalR code anywhere in the application to make this work.

This is a simple case but shows that SignalR really does support "automatic fallback" to earlier transport mechanisms when websockets support is not available on the server.