Aspnetcore: IIS in-process hosting moved out of ASP.NET Core 2.1

[shirhatti]

Discussion for https://github.com/aspnet/Announcements/issues/302

---

We are moving IIS in-process hosting out of the ASP.NET Core 2.1 to give more time to validate the design and implementation. We will ship IIS in-process hosting as part of the ASP.NET Core 2.2 release.

Why?

IIS in-process hosting is a brand new server implementation and hasn't received sufficient attention during the ASP.NET Core 2.1 release for us to feel comfortable shipping it at this time.

[poke]

Isn’t this already included in the 2.1 RTM bits that are already available? Will 2.1.1 remove it then or what is the plan here?

[martincostello]

It’s a shame this wasn’t announced during one of the previous prereleases and has been left until such a last minute, but it does explain why the NuGet package associated with it from 2.1.0-preview1 didn’t receive any further updates.

[Tornhoof]

The relevant parts were removed #807 , so no they are not in anymore

[shirhatti]

Our interim plan was to try and attempt to have in-proc still work with 2.1 even if it meant being unable to release it along with RTM of the rest of 2.1, but rather releasing it as an out-of-band release. This is why we delayed making this announcement as we were still hoping to get it to work with 2.1 up until today.

[shirhatti]

I recognize that we had a sub-par experience for trying in-process hosting in 2.1.0-preview1 and currently exploring options to deliver a better preview experience through the duration of the 2.2 release.

[ericwj]

I noticed the relevant configuration settings are ignored running on 2.1.0-rtm, although web.config schema still recognizes the option in the VS editor. dotnet.exe will be the process regardless.

[ondravondra]

Good thing we're moving away from iis integration and towards docker and nginx. IIS rest in rip ;)

[samcov]

Just a bit of a rant, which in no way should be taken as diminishing the great work done here.

1. This information coming late really screwed up our scheduled deployment plans, earlier knowledge would have helped.

2. Recognizing the potential performance hit, why not build an official reverse proxy in .net core that we can use on linux, windows and mac.

3. Bigger wish: port IIS to Linux... more like a wet dream :)

[felipepessoto]

@samcov, about the 2nd item. I don't think building a reverse proxy is necessary. The main idea about using a reverse proxy is because Kestrel is not mature like IIS or Nginx

[samcov]

@fujiy This is actually being considered by MS right now, they already have a proxy repo and would iterate off of that.

I wasn't thinking of it as a replacement for in-proc, but , IMO, it would appear to be a great compliment to Kestrel, making it useful on all platforms.

No, it doesn't solve all of Kestrel's issues, but it does give users an out of the box solution to the biggest issue... we don't want to use ports in the wild.

[poke]

@samcov Kestrel has already been considered safe to run without a reverse proxy since 2.0. Yes, it is not as advanced as some other front-facing webservers but that also isn’t its goal. If you need advanced features, just use an already established well supported reverse proxy, like nginx or Apache.

Considering that IIS runs on HTTP.sys, and that’s a Windows thing, I would be very surprised if porting IIS onto another platform would ever happen. There’s a reason why Kestrel originally ran on libuv by default, and with the new .NET Sockets in 2.1, there’s hardly a reason left to invest in another transport layer.

Also, considering the further developments for ASP.NET Core and Kestrel, e.g. the host filtering, it is somewhat clear that the direction is to make Kestrel more robust for exposing it directly, instead of adding another layer in front of it.

As for Microsoft.AspNetCore.Proxy, that is a proxy that actually runs as part of your ASP.NET Core application. So no, it is not something that would run in front of it, being a reverse proxy for your app. It is a proxy inside your app that can proxy incoming requests, and as such also runs through Kestrel.

[samcov]

@poke I mostly agree with your post.

Yes http.sys is a windows thing, but so was System.Web, it depends on if they feel there is enough of a win there, like you I doubt it, but as I said, it was a wet dream.

David Fowler stated that they were considering adding a reverse proxy to Kestrel, however he wasn't warm to the idea of it being outside, but part of Kestrel as you stated. He also said that the likely base code for that effort may come from Microsoft.AspNetCore.Proxy, as forward and reverse proxies share common code.

BTW, thanks for the detailed response.

[samcov]

One last thing!

Is there a way to use the out of process ANCM and be able to switch to the new in process model easily, or is it only one or the other?

[Tratcher]

Switching should be trivial. At the moment it's an added dependency, a line of code, and a config switch.

[samcov]

Great! Thanks for the info, now I'll search for a code sample.

[samcov]

FYI for anyone else looking for how to do this, take a look here(at the bottom of the post) ASP.NET Core 2.1.0-preview1: Improvements to IIS hosting

[ericwj]

I don't think these instructions are complete. I got dotnet.exe regardless of applying the project file and web.config settings. @Tratcher also mentioned an added dependency was necessary. The IISIntegration package is not enough - not with 2.1.0-rtm.

[shirhatti]

FYI for anyone else looking for how to do this, take a look here(at the bottom of the post) ASP.NET Core 2.1.0-preview1: Improvements to IIS hosting

Huge caveat here. That blog post was intended for running with 2.1.0-preview1 which had known issues with in-proc hosting. There currently isn't a way to get in-proc to work with 2.1.0-rtm.

We're currently looking at ways to make it easier for folks trying to consume pre-release 2.2 bits for running ANCM in-proc, but bear with us since we don't have an easy way yet.

[ericwj]

Nice! More interested in the SCSS compiler if that is going to be available than in in process hosting.

[samcov]

Great info! I know there are a lot of moving parts, so it's understandable this will take some time.

I guess the advice for now is to just use the out of process solution if you need something today.

[Tornhoof]

We're currently looking at ways to make it easier for folks trying to consume pre-release 2.2 bits for running ANCM in-proc, but bear with us since we don't have an easy way yet.

If you get that working please @ me, as I was already previously testing the 2.1 bits.

[ashutoshsoni]

After upgrade the webapi and web project with asp.net 2.1 stable release we found the issue in iis hosting. I thing aboveboard post is also similar but I did not find right track after read above ...could you please help what options need to check while publishing with dotnet -release ..

Events log Error : webapi showing something dll httpmodule issue.

[NickCraver]

@shirhatti Is there a timing update here?

The 2.2 roadmap is out, and this (IMO major) feature isn't listed on it: https://github.com/aspnet/Announcements/issues/307. I've also asked on the discussion thread for the announcement.

[shirhatti]

@NickCraver Yeah. It was an accidental omission. I'm just about to update the announcement to reflect that that in-proc is a part of 2.2

[NickCraver]

@shirhatti :heart: Awesome.

We're willing to test pre-release bits here by the way (told Glenn the same), please feel free to reach out: craver at stackoverflow.

[VictorioBerra]

Does anyone know if IIS in-process hosting will allow core apps to access session items created by ISAPI modules? More specifically, we use Shibboleth SP on IIS to set session variables after a user logs in, and in non core apps we can get their SAML attributes easily from Session[].

[Tratcher]

@VictorioBerra that's unlikely, ASP.NET Core uses a different implementation for Session. What data do you need specifically, it's likely available via other means. You may want to open your own issue for this topic.

[VictorioBerra]

Yes. Shib SP (ISAPI module) allows for passing the data via headers but my organization does not allow that for security reasons (I have not probed as to why). For Core apps, we have stood up an IdentityServer4 server, with our Shib IdP as an external provider and that has given us a lot of flexibility as an organization for apps of all languages and for protecting resources like APIs.

Just though id elaborate in case someone finds this via a search.

[K3n4]

@ondravondra but it's pain in the . if you want to deploy these containers on windows enviroment

[muratg]

This is shipping in 2.2.

[UweKeim]

So did it actually ship in 2.2?

(According to this documentation, it seems to be the case).

[jkotalik]

Yep!