We might think that IIS is the ideal platform to host ASP.NET Core applications, as it always has been since the first release of ASP.NET. As a matter of fact, it's not. ASP.NET Core web applications run via the highly optimized Kestrel server. Whenever we choose to host one of them with IIS, we basically need it to act as a reverse proxy for the underlying Kestrel server.

The good news is that we don't need to configure anything by ourselves, because the ASP.NET Core template we used back in Chapter 1, Getting Ready, provided us with a root web.config file containing all the settings, to do just that.

The relevant configuration lines should be contained within the <system.webServer> element, which should resemble the following XML code:

<system.webServer> 
  <handlers> 
    <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified"/> 
  </handlers> 
  <aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" stdoutLogEnabled="false" stdoutLogFile=".logsstdout" forwardWindowsAuthToken="false"/> 
</system.webServer> 

We can see that we have a dedicated aspNetCore handler and some related configuration placeholders that will be transformed into actual values upon publication.

As we said earlier, we don't need to change anything, as the handler will do everything by itself, assuming that it is installed on the Web Server. Since ASP.NET Core is a rather new technology, this might as well not be the case, so we could need to download and install it.

At the time of writing, we need to obtain the .NET Core Windows Server Hosting bundle, which conveniently includes all the required packages to host a .NET Core application on a IIS powered server machine: the .NET Core Runtime, the .NET Core Library, the ASP.NET Core module, and also the required reverse proxy between IIS and the Kestrel server.

The bundle can be downloaded from the following URL:

https://go.microsoft.com/fwlink/?LinkId=817246

As soon as we install the .NET Core Windows Server Hosting bundle, we'll be able to configure our IIS instance to host our application.

From the IIS Manager interface, right-click on Sites and choose the Add New Website option. Name it OpenGameList. By looking at the read-only textbox to the immediate right, we can see that a new Application Pool will also be created with that same name. Take a mental note of it, as we'll need to configure it soon enough.

Set the physical path of the Content Directory to the folder we targeted for FTP publishing.

In our previous example, it should be something like C:inetpubOpenGameList, assuming that the FTP root for the web admin user points to C:inetpub.

Be sure to target the application's root folder, not the wwwroot one.

As for the bindings, either choose a specific IP address or leave the All Unassigned option and choose a Host name that is already configured to redirect to our web server via DNS:

In our example, we already set up http://www.opengamelist.com , so we'll just use that.

Before clicking on the OK button, ensure that the Start Website immediately option is checked, so the website will be immediately available.

We can now switch to the Application Pools node. Select the OpenGameList one, the same that we created a short while ago, and set the .NET CLR version to No Managed Code:

This might seem rather counterintuitive, as it looks like we're ruling out ASP.NET. As a matter of fact, that's the exact opposite: since we're publishing an ASP.NET Core application, we need to ensure that the soon-to-be-outdated .NET 4 CLR won't get in the way. Since the former is still (at the time of writing) in a pre-release state, it isn't available yet within the GUI, leaving us with the only option to remove any reference here. We already configured the .NET Core module for IIS to do the required job anyway.