[Announcement] Change to IIS hosting model

[DamianEdwards]

Discussions for aspnet/Announcements#69

[joeaudette]

I have a server that is Windows 2008 Web Server, not R2. Does this mean I won't be able to run ASP.NET 5 on my server?

[DamianEdwards]

@joeaudette ASP.NET 5 was never supported on Windows Server 2008. The minimum requirement was always Windows Server 2008 R2.

[joeaudette]

I guess I understand that but it is a real bummer for me as it is the only server I have. I'm working on a new open source project for asp.net 5 and now I have nowhere to host it.

[regisbsb]

azure

[joeaudette]

yeah but Azure/SqlAzure is kind of expensive for me especially vs a free server that I already have, and especially for an open source project that isn't making me money.

[tomasr]

I'm not entirely sure about the whole plus story here, but this seems like a big step backwards to me.

A few downsides and questions I can see:

• We're changing a robust application hosting platform for.... one that isn't (at least yet). What would the recycling story be here, for example?
• How about support? what tooling would a sysadmin have to quickly figure out which kestrel process belongs to what site/application so they can, for example, capture a dump?
• What's the management story? Seems like now the admin will need to deal with a whole other mess of things.
• What's the performance level of Kestrel as of now? Can it keep up with IIS on the front-end?

[Bartmax]

why Microsoft.AspNet.Server.WebListener server is still an option? I'm just curious.

[jods4]

Does the removal of web.config have any consequence in this new model? For .net we still have app.config, but in <system.webserver> we could configure quite a lot of IIS things. I know most of the stuff is now handled (and configurable) by ASP.NET 5 but probably not everything.

Let's say for a minute that I want to do the static file serving from IIS. Is it possible? If yes, previously I could configure MIME types, compression, etc. from web.config how do I do that now?

[aggieben]

Can we at least have the sources for Helios for those who still want to use it? The reasons given for dropping support sound reasonable, but I kind of agree with @tomasr that there are also downsides, particularly in this early phase of vNext where tooling doesn't have the same level of maturity as tooling that has been around for IIS for a while. That's also not to mention performance impacts @DamianEdwards mentioned, but also downplayed. Maybe dotnet/aspnetcore#58 should be revisited?

[JaredShaver]

So is w3wp.exe totally out of the picture? We have a large number of tuning/performance settings configured for our application pools such as recycling, logging recycle events, CPU limit, idle time out, etc. Do these get flowed to the new model or are those unsupported? What about all the tools, including Microsoft's own such as SCOM APM and DebugDiag. Will those support this new model or will they need significant upgrades?

[TerribleDev]

its just an IIS module that will create a process and proxy requests to said process. I'd assume all of that still needs to run in an app pool as its an IIS module, so its more than likely that app pool recycling will work.

[davidfowl]

@joeaudette Can you use azure for hosting?

[davidfowl]

@aggieben Nope, Helios isn't open source and it won't be. You could always write a native IIS module from scratch but I'd recommend against it.

[davidfowl]

@jods4 web.config and <system.webServer> still work in this new model. IIS configuration is still there, but for .NET based configuration it's not going to be used.

[joeaudette]

@davidfowl I'm going to consider Azure/SqlAzure but I'm worried about the costs.

[evil-shrike]

Cool, but what about IIS7? Isn't it possible to host aspnet apps under IIS7 on Win7 anymore?

[TerribleDev]

I'm actually a huge fan of these changes. The big reason I like this, is that it simplifies the hosting model between OS's

Most likely people hosting DNX in linux will (most likely) proxy the requests through something like Nginx, so I'm glad to see the same idea being implemented in IIS.

This lets all the platforms be equal, and not have Windows seem like a first class citizen.

[jods4]

@davidfowl OK thanks. That's important because it's a lot easier to ship an application to a customer and say "just copy those files over" rather than try to explain them how to configure IIS, which -- although they're supposed to be the server admin -- they are often somehow unable to do properly.

I assume web sockets go through cross-process as well?

[DamianEdwards]

@jods4 websockets flow across the process just fine

[DamianEdwards]

@evil-shrike Windows 7 has IIS 7.5, not IIS 7. We require IIS 7.5 as a minimum and the HttpPlatformHandler is being updated to support running on IIS 7.5

[DamianEdwards]

@Bartmax WebListener is based on HTTP.SYS which has some unique features that certain customers desire that can't be achieved otherwise, e.g. multiple apps listening on a single port. It also serves as the out-of-band replacement for System.Net.HttpListener for traditional .NET self-host applications.

[davidfowl]

@JaredShaver That all continues to work. IIS app pool management works the same way it did. The http platform handler uses windows job objects to keep track of child processes.

[JaredShaver]

@davidfowl thanks for the clarification. @DamianEdwards might want to update the announcement with how this will flow to avoid some IIS administrators being confused.

[Bartmax]

@DamianEdwards thank you for the detailed response. I like very much the decision taken here. 👍

[DamianEdwards]

@tomasr

• IIS is still managing the process. The AppPool settings that control recycling, memory limits, etc. still apply.
• How do you determine which instance of w3wp.exe belongs to which AppPool today? The problem is no different, and the process launched will be a child of the related w3wp.exe instance so things like Process Explorer would show that relationship.
• As above, IIS is still managing the process. You can configure IIS to capture the stdout from the launched process and redirect it to a file. Also, DNX/ASP.NET 5 has a logging story that supports outputting of logs to numerous different sinks, including Windows systems like ETW.
• Kestrel is faster now for running ASP.NET 5 code than IIS is for running ASP.NET 4.x and 5 code, and our goal is to make it many times faster yet. See https://github.com/aspnet/benchmarks for more info.

[benaadams]

Check it locally? e.g. Task Manager -> Performance -> Open Resource Monitor -> Network -> Listening Ports

Find out where dnx (I assume) is listening; then point a localhost browser on the local machine there, make sure ASPNET itself is responding - then you know its a comms issue between the two.

[wgrs]

[benaadams]

First number is Process Id, Second number is port so try:

http://localhost:26101/Index.htm
http://localhost:26101/WebApplication1/Index.htm

[wgrs]

http://localhost:26101/WebApplication1/Index.htm gives a 404

[wgrs]

http://localhost:26101/Index.htm works

[benaadams]

K, so the issue is likely the path mapping as IIS is passing the full path and your app doesn't have anything there.

You can rewrite it with IIS; change your apps routing path; I think give the app a base path, or you can change the application binding to be the website root; rather than a subdirectory.

[wgrs]

So, its a problem of how the app is being deployed?

[benaadams]

You are sending your app urls that are:
http://localhost/WebApplication1/*
and your app is routing for urls that are
http://localhost/*
So there is a mis-match

So, its a problem of how the app is being deployed?

I'm not sure what your intentions are, so I can't tell you. Do you want the app to be straight off the domain / or a subdirectory /WebApplication1/?

[wgrs]

Yes, I understand that. I want it off the subdirectory. Anyway that's a minor fix.

Thanks for all your help and time!!!

[benaadams]

@wgrs this might help aspnet/IISIntegration#14

[wgrs]

Great that looks like the answer = thanks again.

[wgrs]

@benaadams - I tried the fix from the link above but it did not work for me. Until that version is released you can add HTTP_PLATFORM_APPL_PATH to the environment variables section of the httpPlatform web.config with a value like /MySubApplication.

The ports for the dnx.exe are dynamically assigned and there are multiple instances running, so how do I know which one to use?

[Tratcher]

FYI: HttpPlatformHandler is being replaced by AspNetCoreModule: aspnet/IISIntegration#105

[sergeos]

Sorry, maybe someone knows why the first launch of the site takes a lot of time? Is the replacing HttpPlatformHandler help resolve this problem?
I'm trying on Server2008 R2 and Server2012. Starting site about 1 minute for simple form of login.
Other sites based on MVC5 working fast.

[guardrex]

@sergeos I assume a number of perf improvements have been made between rc1-final released back in November and rc2-nightly wrt JIT (guessing, of course, since I haven't compared those two app types directly).

If you do move the app into rc2-nightly format and start using the new module, I noticed startup times were roughly cut in half for shared (portable) apps (less JIT) over standalone (self-contained) apps (more JIT). My figures for a small test app were roughly 20 seconds for the standalone app and <10 seconds for the shared version of an identical app.

I would guess though that as the dependency list gets longer, apps will converge on startup times with shared always being faster but with a declining margin of bonus speed. Any difference should ultimately (mostly) be removed when standalone apps get a native compilation option.

[kuashe]

@sergeos Maybe not the best place for this . As far as i know ASP.NET Core doesn't build anything anymore. MSIL is know only produced when webpages are accessed for the first time (weither this is MVC or not ) .

To force il code generation you can tr y to use CLI "dnu publish" .Note that this is only viable for RC1 , dnu will be removed for RC2 .

Can somebody confirme my statement ?

[guardrex]

@kuashe I think that's a fair ? here tho: Is this more of a hosting prob or an app prob ... it's really more of an app prob. The two modules are just handling reverse proxy and given that the AspNetCoreModule is just a port of the HttpPlatformHandler module, they are probably almost identical in speed. I was thinking that if @sergeos does update for rc2-nightly that some bonuses would be there due to work that's been done on the app compilation side; additionally, the faster speeds of the shared framework runtime (with native bits and less JIT on startup) would probably get that app to startup quicker.

[EDIT] @ArieJones says on JabbR that EF6 bits on rc1 can also cause long compilation times of views. He implies you might get a faster app startup if you can move to EF7.

[xavierjohn]

I saw this post by you back in 2015.
aspnet/Announcements#69
• The HttpPlatformHandler currently does not forward client certs (this will be a future enhancement)

Is this still the case? I noticed Client Certificate is not getting passed to my app in Azure Web App.

[Tratcher]

@xavierjohn We no longer use HttpPlatformHandler, we use AspNetCoreModule (a fork), and yes it does have client cert support.
I suggest you file a new issue with your app details here: https://github.com/aspnet/aspnetcoremodule

[aspnet-hello]

We periodically close 'discussion' issues that have not been updated in a long period of time.

We apologize if this causes any inconvenience. We ask that if you are still encountering an issue, please log a new issue with updated information and we will investigate.