ANCM (AspNetCoreModuleV2) supports IIS In-Process hosting and request cancellation via HttpContext.RequestAborted
or model bound CancellationToken
in controller's action, but only when targeting netcoreapp2.2
.
IIS In-Process hosting and request cancellation do not work for web sites when targeting latest .NET Framework net472
. EXE file compiled for WebSite project when targeting .NET Framework seems not to be compatible with In-process hosting requirements for IIS.
ANCM should support IIS In-Process hosting and request cancellation for both target frameworks: .NET Core and .NET Framework .
There are no plans of supporting .NET Framework in InProcess hosting mode.
I think this is important performance feature to ditch it without taking it into serious consideration.
Further, breaking feature parity of the same project type on granular level like this, does not seem reasonable long term.
At least, this kind of gaps should be clearly stated in the documentation and new release announcements, to help make informed decision upfront, instead of every team/developer having to find this out on their own.
then please add note about in process here https://docs.microsoft.com/en-us/aspnet/core/migration/21-to-22?view=aspnetcore-2.2&tabs=visual-studio I spent 2 days on thing which is not supported :(
@guardrex can you address this?
It's filed here
It's true. Except for saying, "Loads the CoreCLR." ... _"CoreCLR"_ ... we don't address it.
I've prioritized it for this sprint. I'll fix it this week.
Closing this as it's tracked in https://github.com/aspnet/Docs/issues/10297
You might want to fix this pages too, "In-process hosting model" section:
https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/iis/?view=aspnetcore-2.2
https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/aspnet-core-module?view=aspnetcore-2.2
It would be great if you can be more clear and transparent about reasons for omission of this feature for .NET Framework. Perhaps add reasoning behind the decision in the documentation, so that clearer outlook what is correct way to go forward with .NET Framework and .NET Core CLR.
There are no plans of supporting .NET Framework in InProcess hosting mode.
@pakrym , can you please explain? I was under the impression (see for example here) that .Net framework would work until .net core 3, which is a requirement for our team because we rely on a lot of legacy .Net framework code.
To suddenly come out and say, a month or two after release of In-Process hosting, that targeting .Net framework means swallowing the performance hit of proxying to kestrel, was (unintentionally, but still) very misleading, and seems to be breaking the stated goal of
[giving] customers a reasonable stepping stone on their path to migrating applications to ASP.NET Core on .NET Core
@nenadvicentic The docs do mention that in-process model is not supported for .NET Framework. It seems implicit in the docs to me that if you need to use .NET Framework, you'll need to use out-of-proc, and if you're on .NET Core, you can use either model. Do we need to clear the wording a bit?
@yringler .NET Framework works with ASP.NET Core 2.2. Nothing changed there. In-proc hosting model is an extra if you choose to use .NET Core. We're not prioritizing this feature on .NET Framework over many other things we have to do, mainly because implementation of it on .NET Framework would be mostly different than the current implementation, not to mention the extra support costs. The quote you shared is still valid, IMHO.
馃憤
Got it.
Thank you for clarifying things for me.
The docs describe performance, referring to
the out-of-process performance penalty of proxying requests over the loopback adapter
Someone reading this now might worry about the implied high cost of reverse-proxy in out-of-proc hosting. This could discourage adoption of MVC Core in a shop which requires targeting .Net Framework, such as ours.
Could you direct me to documentation of how bad the "performance penalty" is, and how it compares to e.g. running ASP.Net WebForms or MVC 5? I have not been able to find anything.
Perhaps this should be a separate issue; I'm writing here because it follows from the clarification that in-process hosting is no longer an option for us.
@guardrex, can we soften the wording in the doc @yringler mentions above? Penalty is perhaps not the right word. Maybe we can call it the other way around, that in-proc improves perf by removing the loopback adapter requests or something like that.
@yringler We have some perf numbers via microbenchmarks that shows the difference, but that's mainly for us to see where we stand. The biggest difference we see is in "plain text" scenarios, where the server just returns the same text over and over again without doing anything else. In "real world" apps, many other things are at play, apps calling into other services, accessing DBs, caching systems etc.
I recommend doing profiling for your particular scenarios, and see if they're good with out-of-proc IIS for your use case. Even with out-of-proc, I expect most scenarios to run faster than MVC5 or WebForms.
Sure ... I'll open and issue and take care of that.
btw -- There's an open issue for adding a plaintext in-proc benchmark: https://github.com/aspnet/Benchmarks/issues/504 ... it might be to compare in-proc ANCM vs. Kestrel tho and not to compare in-proc vs. out-of-proc.
@muratg
@nenadvicentic The docs do mention that in-process model is not supported for .NET Framework. It seems implicit in the docs to me that if you need to use .NET Framework, you'll need to use out-of-proc, and if you're on .NET Core, you can use either model. Do we need to clear the wording a bit?
The sentence you are referring to was not in the documentation when I started this thread. Not even a hint about it. Now, with sentence included, I think it is clear and sufficient.
The in-process hosting model isn't supported for ASP.NET Core apps that target the .NET Framework.
@nenadvicentic thanks, just wanted to make sure!
Most helpful comment
then please add note about in process here https://docs.microsoft.com/en-us/aspnet/core/migration/21-to-22?view=aspnetcore-2.2&tabs=visual-studio I spent 2 days on thing which is not supported :(