Rick Strahl's Web Log

Wind, waves, code and everything in between...
ASP.NET • C# • HTML5 • JavaScript • AngularJs
Contact   •   Articles   •   Products   •   Support   •   Search
Ad-free experience sponsored by:
ASPOSE - the market leader of .NET and Java APIs for file formats – natively work with DOCX, XLSX, PPT, PDF, images and more

Publishing and Running ASP.NET Core Applications with IIS


When you build ASP.NET Core applications and you plan on running your applications on IIS you'll find that the way that Core applications work in IIS is radically different than in previous versions of ASP.NET.

In this post I'll explain how ASP.NET Core runs in the context of IIS and how you can deploy your ASP.NET Core application to IIS.

IIS and ASP.NET Core

The most important thing to understand about hosting ASP.NET Core is that it runs as a standalone, out of process Console application. It's not hosted inside of IIS and it doesn't need IIS to run. ASP.NET Core applications have their own self-hosted Web server and process requests internally using this self-hosted server instance.

You can however run IIS as a front end proxy for ASP.NET Core applications, because Kestrel is a raw Web server that doesn't support all features a full server like IIS supports. This is actually a recommended practice on Windows in order to provide port 80/443 forwarding which kestrel doesn't support directly. For Windows IIS (or another reverse proxy) will continue to be an important part of the server even with ASP.NET Core applications.

Let's take a look and see how IIS fits into ASP.NET Core applications.

Classic ASP.NET Hosting

Before we take a look at ASP.NET Core hosting lets review how classic ASP.NET runs ASP.NET applications:

Hosting ASP.NET on IIS

In a classic ASP.NET application everything is hosted inside of an IIS Worker Process (w3wp.exe) which is the IIS Application Pool. The AppPool hosts your ASP.NET application and your application is instantiated by the built-in ASP.NET hosting features in IIS. The native runtime manager instantiates the .NET Runtime on your application's behalf and brings up the HttpRuntime object which is then used to fire requests through the ASP.NET application pipeline as requests come in from the native http.sys driver. Requests come in from http.sys and are dispatched to the appropriate site that is mapped to the Application Pool and the HttpRuntime instance hosted there.

ASP.NET Core with IIS

Things are quite different with ASP.NET Core which doesn't run in-process to the IIS worker process, but rather runs as a separate, out of process Console application that runs its own Web server using the Kestrel component. Kestrel is a .NET Web Server implementation that has been heavily optimized for throughput performance. It's fast and functional in getting network requests into your application, but it's 'just' a raw Web server. It does not include Web management services as a full featured server like IIS does.

If you run on Windows you will likely want to run Kestrel behind IIS to gain infrastructure features like port 80/443 forwarding via Host Headers, process lifetime management and certificate management to name a few.

Here's what it looks like when you run your ASP.NET Core application behind an IIS Web front:

ASP.NET Core IIS Hosting

ASP.NET Core applications are standalone Console applications invoked through the dotnet runtime command. They are not loaded into an IIS worker process, but rather loaded through a native IIS module called AspNetCoreModule that executes the external Console application.

The AspNetCoreModule has to be installed on your server and is part of the ASP.NET Core Server Hosting Bundle.

Once you've installed the hosting bundle (or you install the .NET Core SDK on your Dev machine) the AspNetCoreModule is available in the IIS native module list:

The ASPNetCoreModule interfaces ASP.NET Core Console Applications

The AspNetCoreModule is a native IIS module that hooks into the IIS pipeline very early in the request cycle and immediately redirects all traffic to the backend ASP.NET Core application. All requests - even those mapped to top level Handlers like ASPX bypass the IIS pipeline and are forwarded to the ASP.NET Core process. This means you can't easily mix ASP.NET Core and other frameworks in the same Site/Virtual directory, which feels a bit like a step back given that you could easily mix frameworks before in IIS.

While the IIS Site/Virtual still needs an IIS Application Pool to run in, the Application Pool should be set to use No Managed Code. Since the App Pool acts merely as a proxy to forward requests, there's no need to have it instantiate a .NET runtime.

The AspNetCoreModule's job is to ensure that your application gets loaded when the first request comes in and that the process stays loaded if for some reason the application crashes. You essentially get the same behavior as classic ASP.NET applications that are managed by WAS (Windows Activation Service).

Once running, incoming Http requests are handled by this module and then routed to your ASP.NET Core application.

So, requests come in from the Web and int the kernel mode http.sys driver which routes into IIS on the primary port (80) or SSL port (443). The request is then forwarded to your ASP.NET Core application on the HTTP port configured for your application which is not port 80/443. In essence, IIS acts a reverse proxy simply forwarding requests to your ASP.NET Core Web running the Kestrel Web server on a different port.

Kestrel picks up the request and pushes it into the ASP.NET Core middleware pipeline which then handles your request and passes it on to your application logic. The resulting HTTP output is then passed back to IIS which then pushes it back out over the Internet to the HTTP client that initiated the request - a browser, mobile client or application.

The AspNetCoreModule is configured via the web.config file found in the application's root, which points a the startup command (dotnet) and argument (your application's main dll) which are used to launch the .NET Core application. The configuration in the web.config file points the module at your application's root folder and the startup DLL that needs to be launched.

Here's what the web.config looks like:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <!--
    Configure your application settings in appsettings.json. Learn more at http://go.microsoft.com/fwlink/?LinkId=786380
  -->
  <system.webServer>
    <handlers>
      <add name="aspNetCore" path="*" verb="*"
        modules="AspNetCoreModule" resourceType="Unspecified" />
    </handlers>
    <aspNetCore processPath="dotnet"
                arguments=".\AlbumViewerNetCore.dll" 
                stdoutLogEnabled="false" 
                stdoutLogFile=".\logs\stdout" 
                forwardWindowsAuthToken="false" />
  </system.webServer>
</configuration>

You can see that module references dotnetexe and the compiled entry point DLL that holds your Main method in your .NET Core application.

Do you need IIS?

We've already discussed that when running ASP.NET Core on Windows, it's recommended you use IIS as a front end proxy. While it's possible to directly access Kestrel via an IP Address and available port, there are number of reasons why you don't want to expose your application directly this way in production environments.

First and foremost, if you want to have multiple applications running on a single server that all share port 80 and port 443 you can't run Kestrel directly. Kestrel doesn't support host header routing which is required to allow multiple port 80 bindings on a single IP address. Without IIS (or http.sys actually) you currently can't do this using Kestrel alone (and I think this is not planned either).

The AspNetCoreModule running through IIS also provides the necessary process management to ensure that your application gets loaded on the first access, ensures that it stays up and running and is restarted if it crashes. The AspNetCoreModule provides the required process management to ensure that your AspNetCore application is always available even after a crash.

It's also a good idea to run secure SSL requests through IIS proper by setting up certificates through the IIS certificate store and letting IIS handle the SSL authentication. The backplane HTTP request from IIS can then simply fire a non-secure HTTP request to your application. This means only a the front end IIS server needs a certificate even if you have multiple servers on the backplane serving the actual HTTP content.

IIS can also provide static file serving, gzip compression of static content, static file caching, Url Rewriting and a host of other features that IIS provides natively. IIS is really good and efficient at processing non-application requests, so it's worthwhile to take advantage of that. You can let IIS handle the tasks that it's really good at, and leave the dynamic tasks to pass through to your ASP.NET Core application.

The bottom line for all of this is if you are hosting on Windows you'll want to use IIS and the AspNetCoreModule.

Running IIS as a Development Server - no

So I've seen this question comes up occasionally:

Can I run full IIS to run and debug my ASP.NET Core Applications like I could with classic applications?

To sidestep this question a little: There should be very few reasons for you to run IIS during development. Yes, in the past there were very good reasons to run full IIS because there were always a number of things that behaved very differently in full IIS compared to IIS Express.

However, with ASP.NET Core there's little to no reason to be running full IIS during development. Why? Because ASP.NET Core applications aren't actually running inside of IIS. Whether you running called from IIS, IIS Express or whether you do dotnet run directly from the command line - you are running the exact same code and in most cases the exact same execution environment. Running inside of IIS really doesn't buy you anything anymore that you can't easily simulate with a command line environment.

The only reason you might need to run under IIS if there is something that IIS provides in terms of HTTP services that is really separate from the ASP.NET Core processing. But even then it's likely that those features won't be something you need to debug in the context of your application.

'Running' IIS

The reason that you can't 'just run IIS' from your development environment is that an ASP.NET Core application has to be published before it can be executed. The development folder doesn't hold all the files necessary to run your application. When you 'debug' or 'run' your application the application is first published to a separate location and run from there. For this reason you don't see IIS as an option in Visual Studio for example.

If you absolutely have to run with IIS, you can publish the application to a local folder first, then configure an IIS virtual directory or site and use that to run your site.

Publishing ASP.NET Core Applications for IIS

In order to run an application with IIS you have to first publish it. There are two ways to that you can do this today:

  • Use dotnet publish
  • Use the Visual Studio Publishing Features

Using dotnet publish

Using dotnet publish builds your application and copies a runnable, self-contained version of the project to a new location on disk. You specify an output folder where all the files are published. This is not so different from classic ASP.NET which ran Web sites out of temp folders. With ASP.NET Core you explicitly publish an application into a location of your choice - the files are no longer hidden away and magically copied around.

A typical publish command may look like this:

dotnet publish
      --framework netcoreapp1.0 
      --output "c:\temp\AlbumViewerWeb" 
      --configuration Release

This publishes the application to the c:\temp\albumviewerWeb.

If you open this folder you'll find that it contains your original application structure plus all the nuget dependency assemblies dumped into the root folder:

Manual IIS Hosting of a Publish Folder

Once you've published your application and you've moved it to your server (via FTP or other mechanism) we can then hook up IIS to the folder.

I'm going to create a virtual Application directory:

Note that I created an AspNetCore Application Pool that has its .NET Runtime set to No Managed Code as shown earlier.

IIS Identity and Permissions

You might also have to tweak the IIS App Pool Identity to something other than the default ApplicationPoolIdentity in order to ensure that your application has access to resources it needs to run. I generally start with NETWORKSERVICE and then move to a custom account that matches the actual rights required by the application.

And that's really all that needs to happen. You should be able to now navigate to your site or Virtual and the application just runs.

You can now take this locally deployed Web site, copy it to a Web Server (via FTP or direct file copy or other publishing solution), set up a Site or Virtual and you are off to the races.

Publishing from Visual Studio

The dotnet publish step works to copy the entire project to a folder, but it doesn't actually publish your project to a Web site (currently - this is likely coming at a later point).

In order to get incremental publishing to work, which is really quite crucial for ASP.NET Core applications because there are so many dependencies, you need to use MsDeploy which is available as part of Visual Studio's Web Publishing features.

Currently the Visual Studio Tooling UI is very incomplete, but the underlying functionality is supported. I'll point out a few tweaks that you can use to get this to work today.

When you go into Visual Studio in the RC2 Web tooling and the Publish dialog, you'll find that you can't create a publish profile that points at IIS. There are options for file and Azure publishing but there's no way through the UI to create a new Web site publish.

However, you can cheat by creating your own .pubxml file and putting it into the \Properties\PublishProfiles folder in your project.

Version Specific Workaround

Note it's almost certain this will get fixed post RC2 with a tooling update, so before you go through these steps if you read this article a month from now, check whether you can create an IIS publish profile directly through the Visual Studio UI.

To create a 'manual profile' in your ASP.NET Core Web project:

  • Create a folder \Properties\PublishProfiles
  • Create a file <MyProfile>.pubxml

You can copy an existing .pubxml from a non-ASP.NET Core project or create one. Here's an example of a profile that works with IIS:

<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <WebPublishMethod>MSDeploy</WebPublishMethod>
    <LastUsedBuildConfiguration>Release</LastUsedBuildConfiguration>
    <LastUsedPlatform>Any CPU</LastUsedPlatform>
    <SiteUrlToLaunchAfterPublish>http://samples.west-wind.com/AlbumViewerCore/index.html</SiteUrlToLaunchAfterPublish>
    <LaunchSiteAfterPublish>True</LaunchSiteAfterPublish>
    <ExcludeApp_Data>False</ExcludeApp_Data>
    <PublishFramework>netcoreapp1.0</PublishFramework>
    <UsePowerShell>True</UsePowerShell>
    <EnableMSDeployAppOffline>True</EnableMSDeployAppOffline>
    <MSDeployServiceURL>https://publish.west-wind.com</MSDeployServiceURL>
    <DeployIisAppPath>samples site/albumviewercore</DeployIisAppPath>
    <RemoteSitePhysicalPath />
    <SkipExtraFilesOnServer>True</SkipExtraFilesOnServer>
    <MSDeployPublishMethod>RemoteAgent</MSDeployPublishMethod>
    <EnableMSDeployBackup>False</EnableMSDeployBackup>
    <UserName>username</UserName>
    <_SavePWD>True</_SavePWD>
    <ADUsesOwinOrOpenIdConnect>False</ADUsesOwinOrOpenIdConnect>
    <AuthType>NTLM</AuthType>
  </PropertyGroup>
</Project>

AuthType NTLM Fix

Note the <AuthType>NTLM</AuthType> key at the bottom of the file. This key is very important or else the publish operation doesn't work. If you're copying from an existing file make sure you add this key as it's unlikely to have it by default.

Once you've created a .pubxml file you can now open the publish dialog in Visual Studio with this Profile selected:

At this point you should be able to publish your site to IIS on a remote server and use incremental updates with your content.

#And it's a Wrap Currently IIS hosting and publishing is not particularly well documented and there are some rough edges around the publishing process. Microsoft knows of these issues and this will get fixed by RTM of ASP.NET Core.

In the meantime I hope this post has provided the information you need to understand how IIS hosting works and a few tweaks that let you use the publishing tools available to get your IIS applications running on your Windows Server.

Rock on...

Posted in ASP.NET Core  ASP.NET  

The Voices of Reason


 

Marcin
June 06, 2016

# re: Publishing and Running ASP.NET Core Applications with IIS

Great explanation of the things behind IIS + ASP.NET Core, thanks!

Mort
June 06, 2016

# re: Publishing and Running ASP.NET Core Applications with IIS

Thanks, that was a pretty good article. Well written and clearly understandable and useful.

Alex Sarafian
June 07, 2016

# re: Publishing and Running ASP.NET Core Applications with IIS

Excellent article and thank you for the effort.
One small remark though.
As far as I know, you get one W3WP.exe process per application pool. If the pool is shared between multiple websites or web applications then you get one process.

Having said that, the new pipeline is not that different after all.
The application pool acted as a process template and as with all new modern stuff, your application fully owns the process.

What was not 100% clear for me is whether IIS as reverse proxy does SSL offloading also? And if yes, then does it have to?

Michael
June 07, 2016

# re: Publishing and Running ASP.NET Core Applications with IIS

So how or where do I add URL rewrite? I'm having problems with my angular app using the html5mode

Tyler
June 07, 2016

# re: Publishing and Running ASP.NET Core Applications with IIS

Rick, this is a great article. I want to find a parallel article to being able to use Apache as the reverse proxy on Linux.

Fred Peters
June 07, 2016

# re: Publishing and Running ASP.NET Core Applications with IIS

Thanks Rick for this information. Our group's architect has spent two weeks trying to get our large application updated to RC2. Getting the app to run under IIS in our User Acceptance server has been tedious.

So I assume somewhere back up the line IIS Express was fitted with its version of the AspNetCoreModule.

rtur
June 07, 2016

# re: Publishing and Running ASP.NET Core Applications with IIS

I wish I have this guide few weeks back when I was banging my head against the wall. Still learned few tricks, thanks for sharing. Maybe NTLM bit will fix my Azure profile crashing VS, have to try it out.

Rick Strahl
June 07, 2016

# re: Publishing and Running ASP.NET Core Applications with IIS

@Michael - re: UrlRewrite, that's a good question. As far as I can see AspNetCoreModule bypasses the entire IIS Pipeline including UrlRewrite. I'm trying to find out more and do a follow up article on some of the implications of running with IIS this way. For now it seems it's an all or nothing aproach - you need to let Kestrel do all the Web server functionality including internal app routing. The alternative is to have a root site that uses standard IIS, and a virtual that runs the AspNetCore app which would allow you to separate out the features.

@Tyler - I don't know about how to set up Apache, but the more common scenario is using nginx on Linux. This topic covers nginx in the ASP.NET documentation: https://docs.asp.net/en/latest/publishing/linuxproduction.html?highlight=nginx

@Alex - Application Pools WERE the process in classic ASP.NET. In ASP.NET Core you have both the Application Pool process AND the AspNetCore process active. Since the Application Pool just acts as a proxy it's not going to be super resource intensive, so you can probably host all your ASP.NET Core apps through a single Application Pool/Proxy which is the scenario shown in the figure.

hashname
June 09, 2016

# re: Publishing and Running ASP.NET Core Applications with IIS

Thank you Rick. I wish .Net Core team would publish articles which lays things out as clearly as you do. :)

Rick Strahl
June 09, 2016

# re: Publishing and Running ASP.NET Core Applications with IIS

@hashname - Thank you for the kind words. But credit where credit is due - the new ASP.NET docs (and also the .NET Core docs) are actually very good. Maybe not in high level topics, but for the nuts and bolt stuff I've been very impressed with the quality of the actual platform docs. Especially when you compare to the hell that is MSDN documentation.

TJ
June 15, 2016

# re: Publishing and Running ASP.NET Core Applications with IIS

Unfortunately, publishing ASP.NET Core 1.0 RC2 Web sites to a remote IIS server as non-administrator still does not work in Visual Studio 2015. Due to this, preview and publish fails if the user account set in the publishing profile is not a member of the Administrators group on the remote server.

However, it is possible to resolve both issues as shown below.

Workaround for the Publish-ASP.NET_Core_1.0_RC2-application-to-IIS-as-non-administrator-fails issue:

1) Back up C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\Microsoft\Web Tools\Publish\Scripts\1.1.0\publish-module.psm1

2) Open C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\Microsoft\Web Tools\Publish\Scripts\1.1.0\publish-module.psm1

3) Go to line 694

4) Replace

(InternalNormalize-MSDeployUrl -serviceUrl $publishProperties['MSDeployServiceURL'] -serviceMethod $serviceMethod),

with

(InternalNormalize-MSDeployUrl -serviceUrl ($publishProperties['MSDeployServiceURL'] + '/msdeploy.axd?site=' + $publishProperties['DeployIisAppPath'].Split('/')[0]) -serviceMethod $serviceMethod),

Note: Do the same for C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\Web\Powershell\1.1.0\publish-module.psm1 as you see fit.


Workaround for the Publish-ASP.NET_Core_1.0_RC2-application-to-IIS-as-non-administrator-Preview-fails issue:

1) Back up C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\DotNet\Microsoft.DotNet.Publishing.targets

2) Open C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\DotNet\Microsoft.DotNet.Publishing.targets

3) Go to line 248

4) Replace

<ComputerName>$(MsDeployServiceUrl)</ComputerName>

with

<ComputerName>$(MsDeployServiceUrl)?site=$(DeployIisAppPath.Split('/')[0])</ComputerName>


Now, you should be able to import your Web publishing profile (i.e. example.com.publishsettings) and preview/publish without issues.

Publishing Profile Example (Site):

<?xml version="1.0" encoding="utf-8"?>
<publishData>
<publishProfile
profileName="example.com - Web Deploy"
publishMethod="MSDeploy"
publishUrl="remote.server:8172"
msdeploySite="example.com"
userName="examplecom_pub"
userPWD="PASSWORD_HERE"
destinationAppUrl="http://example.com/"
/>
</publishData>

Publishing Profile Example (Site/Application):

<?xml version="1.0" encoding="utf-8"?>
<publishData>
<publishProfile
profileName="example.com - application - Web Deploy"
publishMethod="MSDeploy"
publishUrl="remote.server:8172"
msdeploySite="example.com/application"
userName="examplecompub"
userPWD="PASSWORD_HERE"
destinationAppUrl="http://example.com/application"
/>
</publishData>


Note: The 'approot' folder no longer exists in RC2, Web Deploy permissions are only required to be set on the 'wwwroot' folder (like it was in the past...)!

Dan Kellett
July 08, 2016

# re: Publishing and Running ASP.NET Core Applications with IIS

This was extremely helpful. Thank you.

Felix
July 10, 2016

# re: Publishing and Running ASP.NET Core Applications with IIS

Thank you - this article puts together many things that we guessed using "trial and error". There are still several things that are puzzling. As somebody mentioned, WebDAV publishing to the server isn't yet available, and simply publish to local directory and copy to remote server doesn't work because many DLLs are locked. So, one needs to stop the site, then copy files, then start again. A few other idiosyncrasies like that.

However, the biggest problem that I can't find any guidance is virtual directory support (not app in virtual directory, but virtual directory inside the app). We had a pointer to UNC path that contained picture gallery. Short of moving gigabytes of data to IIS server, I can't figure out how to do that...

If anybody knows some post that explains it - I would greatly appreciate the pointer

Mike Hillman
July 11, 2016

# re: Publishing and Running ASP.NET Core Applications with IIS

Thanks. You have a gift for explaining the technical.

Ted
July 12, 2016

# re: Publishing and Running ASP.NET Core Applications with IIS

Thanks Rick. Great Article (as are many of your other posts)!

Do you know if it is possible to host two web sites on IIS (on the same server) and have the ASP.NET core site use a port other than 80? I have two web sites one asp.net 5 and one .net core and if I switch the asp.net 5 site to a different port (8080) and use port 80 for the .net core site both sites work fine. If I use port 8080 for the .net core site (and 80 for the asp.net 5 site) when I browse to the .net core site I get an error that "The site cannot be reached".

Jandler Mayer
August 04, 2016

# re: Publishing and Running ASP.NET Core Applications with IIS

Hello Rick,

Thanks for the article. It was very informative on the inner working on IIS.

I followed it to deploy my very basic site created by following the two links (https://docs.asp.net/en/latest/getting-started.html, https://docs.asp.net/en/latest/publishing/iis.html) but I ran into a prickle.

It seems when I set my application pool to No Managed Code / Integrated, I keep getting

"HTTP Error 500.24 - Internal Server Error

An ASP.NET setting has been detected that does not apply in Integrated managed pipeline mode."

If I change it to .NET 4 / Integrated, it works.
If I change it to No Managed/Classic, it works also.

Do you have an idea on how to debug this situation? I do see the dotnet.exe running my dll.

Rick Strahl
August 04, 2016

# re: Publishing and Running ASP.NET Core Applications with IIS

@Jandle - either you have an ASP.NET setting in your Web.config for the application, or - more likely - you're using a virtual directory and that virtual is inheriting settings from the parent site. You might try this again with a top level site and see if that changes the behavior.

Jandler
August 04, 2016

# re: Publishing and Running ASP.NET Core Applications with IIS

@Rick

I deployed my app inside a new web site right under the "sites" folder in IIS. There is no virtual folder and as far as I can tell there is no parent site.

My web.config is actually quite simple

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
    </handlers>
    <aspNetCore processPath="dotnet" arguments=".\aspnetcoreapp.dll" stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout" />
  </system.webServer>
</configuration>


What's weird is that I just tried the same setup on another machine and it works.

Brian Edwards
August 18, 2016

# re: Publishing and Running ASP.NET Core Applications with IIS

Hi Rick,

This is great. My web site when created had "emitEntryPoint": true in build options and was creating an .Exe by default. When I deployed it to IIS it worked fine. I wanted to change it to a DLL so I don't have to recycle the app pool every time I publish. I made the changes to web.config to processPath="dotnet" arguments="websitename.dll" (previously processPath was the .exe and arguments was empty). But now I get HTTP Error 502.5 - Process Failure and in the event log it just has:
Failed to start process with commandline '"dotnet" websitename.dll', ErrorCode = '0x80004005'.

Any other steps you are aware of to fix that, it seems Visual Studio defaults has emitEntryPoint: true when it creates a web site.

Thanks!

Brian Edwards

jdan
August 19, 2016

# re: Publishing and Running ASP.NET Core Applications with IIS

I just spent hours/days trying to work with this and the asp.net docs (which I don't think are anywhere near as good as you suggest, but there you go), cursing all the while, wondering why this didn't work when I realized I was under a slightly different scenario:

I am creating an ASP.NET core app, but have to 'target' (not sure that's the right terminology here) net461 as the framework.

This creates an exe, not a dll, just for one obvious difference, but ultimately, the main difference is that I just don't think this scenario works yet. I can get a site deployed locally, but it just doesn't work (stdout tells me there's something running at a local port that is being fronted by IIS) but the site doesn't produce any output. No errors, just doesn't work.

BTW, I completely disagree about not being able to run under IIS for development. There are SO many differences running under IIS Express, the very least of which is, say, trying to browse from another machine to your dev box to test different scenarios (like, say, hitting it with a real mobile device instead of emulation). But that's another topic.

Rick Strahl
August 21, 2016

# re: Publishing and Running ASP.NET Core Applications with IIS

@Brian - Yeah the post was originally written for RC2 and then updated for RTM so I think the emitEntryPoint setting got added to the default template properly.

@jdan - Yes I haven't tried targeting net461 so not sure how that would work, although that's definitely a scenario that should work. Personally I think if you are targetting 461 you're better off just creating a standard ASP.NET app rather than a core app, but regardless this should work. I can't check this right now as I'm out travelling, but maybe somebody else can confirm that they got running net461 working under IIS.

Re: IIS Express - you can enable remote access with IIS Express by opening up the ports you can use 'netsh add urlacl url=http://*:23434/ user=username listen=yes'. Not automatic for sure, but it works.

jdan
August 22, 2016

# re: Publishing and Running ASP.NET Core Applications with IIS

Rick:

I totally agree it should work.

I'm guessing my scenario is one that is going to be pretty common. I have a dependency that cannot as of yet be recompiled under .NET Core, so I have an otherwise 'pure' Asp.NET Core using all its shiny new features, but I have to target 461 until the dependency can be updated.

Trying various build options to see if that works.....

Scott Addie
August 22, 2016

# re: Publishing and Running ASP.NET Core Applications with IIS

@Rick - I'm looking to do the same thing as @jdan, mostly because my client isn't ready for .NET Core yet. The only difference is that this will be deployed either on-prem or in Azure. Any reasons in particular why you'd recommend sticking with standard ASP.NET when targeting .NET Framework? Just want to make sure there's not something I'm unaware of before I go too far down the "ASP.NET Core with .NET Framework" path.

jdan
August 23, 2016

# re: Publishing and Running ASP.NET Core Applications with IIS

Thank goodness, it was a Pebkac issue.

At some point, they went from publishOptions exclude to publishOptions include, and I horked it up.

Once I figured out that it was serving static files, it became easier to track down.

Whew. I am always satisfied when it is idiot developer issue and not something more serious.

Saf
September 25, 2016

# re: Publishing and Running ASP.NET Core Applications with IIS

After following you article I'm getting blank page when I run the app as localhost/myPublishedFolder. What I may be missing? I've VS2015 and ASP.NET Core 1.0 on Windows 10. This is an ASP.NET MVC Core app on local machine.

Mike Wang
September 28, 2016

# re: Publishing and Running ASP.NET Core Applications with IIS

There is not a single mention of the version of IIS that works with ASP.NET CORE.

On the DOD mil sites we still are on Windows 2008 R2 with IIS 7 and 7.7.

So anyone, Can ASP.NET CORE be deployed on IIS 7?

Rick Strahl
September 28, 2016

# re: Publishing and Running ASP.NET Core Applications with IIS

@Mike - it works with Windows 2008 R2. I am not sure about original Server 2008 though. You're right though - there are no requirements posted that I could find in a casual search.

Gina
October 07, 2016

# re: Publishing and Running ASP.NET Core Applications with IIS

Great article Rick!
If anyone can answer this, it would be you- or anyone else reading your article.

I have successfully deployed an asp net core app, utilizing IIS 7.5 and I need to run a sub application (ver 4.6) under it.. accessing it with the domain.com/newapp/. I have the asp net core app with an app pool "No managed code" (works fine), and I pointed to a different app pool for the sub application "v4.0 Integrated" - but, it won't run "HTTP Error 502.5 - Process Failure".

I can't find anywhere explaining how to do this.

Any help appreciated! Thanks!

Rick Strahl
October 07, 2016

# re: Publishing and Running ASP.NET Core Applications with IIS

@Gina - I'm not sure if that will work because the parent web.config will determine features in the sub folder. You can **try** removing the AspNetCoreModule explicitly from the module list in the subfolders and see if that might work.

buehler
October 10, 2016

# re: Publishing and Running ASP.NET Core Applications with IIS

If you're publishing to say the E:/ and you have installed the .NET Core Windows Server Hosting package (which will install the dotnet.exe on C:/) will this cause 500.19? When I publish and in IIS 7.5 I give the AppPoolIdentity rights to the directory, it is continuing to throw the 500.19 error, but all the way down to the C:/temp/Microsoft.Net/Frameworks64/2.0876483 directory. Which is making no sense at all!!! Please help! I developed the WebAPI on my Mac and followed all instructions to the letter, yet, I still cannot get past the 500.19 error. If I perform the "dotnet run" from the root directory via console, then navigate to http://localhost:5000/swagger/ui it looks beautiful.....else if I attempt to navigate to the url set in the host header (https://api.mysite.com:443) it throws the 500.19 error detailed above. Thank you for any assistance in advance!!!!

Ruard van Elburg
October 19, 2016

# re: Publishing and Running ASP.NET Core Applications with IIS

I've managed to publish a website on Windows 7, IIS 7.5. Only problem I've encountered during publishing was that I had to install PowerShell 3. It runs without problems, but I've noticed one thing: when I request a page the first time it takes about 10 seconds to load (for each page). Is there a way to speed this up?

Since it takes so long to load a page the first time, I do not want IIS to set the site to Idle after the specified timeout. I can prevent this by setting 'Idle timeout' (and Recycle) to zero in the advanced settings of the Application Pool. This 'fixes' the long loading time problem. But I wonder, what is best practice? Is it a task anyway of IIS to recycle or set the website to Idle?

Rick Strahl
October 22, 2016

# re: Publishing and Running ASP.NET Core Applications with IIS

@Ruard - 10 seconds for the first hit on the site seems about right, but only for the first page - not for each new page. There might be somehting else going on.

As to application timeouts - if you're running a dedicated site on your in house servers and you know you have enough resources to run your site(s), there's no reason to idle the site. But if you're running a lot of sites then idling can free up some memory for sites that are busy. Any site that's reasonably busy and public facing probably never goes idle anyway. Either way you can control this via the AppPool settings in IIS.

+++ Rick ---

Pranay
October 25, 2016

# re: Publishing and Running ASP.NET Core Applications with IIS

I am unable to access the web application on other machine in my network, but it runs successfully on my machine. Any idea what more i need to do to make it work on another machine ?

Rick Strahl
October 25, 2016

# re: Publishing and Running ASP.NET Core Applications with IIS

@Pranay - make sure the firewall allows your app to run over the port you are using.

Vik Shah
November 28, 2016

# re: Publishing and Running ASP.NET Core Applications with IIS

0 down vote I had a same issue . I changed application pool identity to network service account . Then I explicitly set the path to dotnet.exe in the web.config for the application to work properly as @danielyewright said in his github(https://github.com/aspnet/Hosting/issues/844) comment . It works after set the path.

Thanks


Brian
December 02, 2016

# re: Publishing and Running ASP.NET Core Applications with IIS

Thanks for the great article Rick. I've just built my first Dot Net Core/Angular 2 app and then followed your guide here and my website opened on the first try! Awesome! Thanks again, Brian.


Paul Mason
December 15, 2016

# re: Publishing and Running ASP.NET Core Applications with IIS

Having just deployed my first Core application, this article was most useful, thanks. I've encountered an issue with the routing if the Core application is loaded as an IIS application, such that the IIS application folder name gets missed out when I'm trying to redirect in code. So if my URL is https://mydomain/myapplicationname/identity/login and I try to redirect to https://mydomain/myapplicationname/home/index with an RedirectResult = "/home/index", what actually happens is that it redirects to https://mydomain/home/index, which raises an error. I've enquired in the asp.net forums about this and no-one seems to have a reasonable answer (the only suggestion has been this https://github.com/aspnet/IISIntegration/issues/14 which implies a fix, but never gets round to a clear conclusion). I've created a workaround by using a string saved as an appsetting. Or should we be creating Websites (which creates problems with having lots of port addresses being used up)?


ttm
December 19, 2016

# re: Publishing and Running ASP.NET Core Applications with IIS

One important question (at least for me): is this applicable only for Asp.Net Core application or it is the way to go for Asp.Net Core Application referencing v4.6.1 Framework?


John
December 29, 2016

# re: Publishing and Running ASP.NET Core Applications with IIS

Hi sailor! Even though I never mastered to carve while keep planing (I guess I never tried hard enough), your instruction to deploy worked perfectly. Thank you!


John Mark Isaac Madison
January 04, 2017

# re: Publishing and Running ASP.NET Core Applications with IIS

IIS and "dotnet run" are using two different execution environments I think. Juding by how running with IIS works, but "dotnet run" gets compilation errors.

Any tips on how to remedy?


Rick Strahl
January 05, 2017

# re: Publishing and Running ASP.NET Core Applications with IIS

@John - no they use different hosting environments. Code should work the same. dotnet run uses Kestrel by default, but you can change what it runs using either the configuration settings mentioned in this post: https://weblog.west-wind.com/posts/2016/Sep/28/External-Network-Access-to-Kestrel-and-IIS-Express-in-ASPNET-Core


pran
January 11, 2017

# re: Publishing and Running ASP.NET Core Applications with IIS

superb explanation of the inner workings of Core with IIS. Do you plan to update this article for the latest version of Asp.Net Core?


Edgars
January 12, 2017

# re: Publishing and Running ASP.NET Core Applications with IIS

Thanks for this article - very helpful. I have succesfully deployed my first ASP.NET Core API with IIS.

Maybe someone here can answer to my question. In previous ASP.NET Web API v2 it was possible to return Status Code pages from IIS. Actually this functionality worked by default without additional configuration. Is it possible to achieve same functionality with ASP.NET Core deployed on IIS? Respectively - return status code pages from IIS.

 

West Wind  © Rick Strahl, West Wind Technologies, 2005 - 2017