[Announcement] Change to IIS hosting model

[DamianEdwards]

Discussions for aspnet/Announcements#69

[guardrex]

FYI: There is some additional helpful info and links in Announcing the Release of the HttpPlatformHandler Module for IIS 8+.

One thing I don't see addressed anywhere is how to bind to multiple domains and/or ports through the arguments parameter of httpPlatform. Every example only shows one binding. How is that done?

[mcoburnwa]

I would like to know if you expect it will be possible that when IIS is configured to reverse proxy requests to Kestrel, that it will still be possible to send requests to Kestrel by connecting a client directly to Kestrel's socket? Secondly, what kind of SSL support does or will Kestrel have for v1 and how is that configured? I assume that if the web app is configured to use SSL that the HttpPlatformHandler will be talking to Kestrel via SSL.

[anfomin]

@davidfowl may be you can help... I still can't run kestrel sample on Azure or local IIS. I've upgraded sample to beta8. When I publish one using dnu publish command I receive output: https://www.dropbox.com/s/c2cre63yq9kb0yz/KestrelOnAzure-beta8.zip?dl=0

I've tried to publish this to Azure or run on local IIS (Windows 10) with HttpPlatformHandler 1.0 installed. I receive:

There are many errors in windows event log:

HttpPlatformHandler generates many log files in logs directory but they are empty.

[davidfowl]

1.0 of HttpPlatformHandler doesn't work with the way kestrel works with publish in beta8. We're depending on a few new features (namely support for relative paths) that are being made to the module. Try changing the log path and the processPath to physical paths. That might work.

[anfomin]

@davidfowl I've changed paths in the web.config to absolute (running in Azure):

<configuration>
  <system.webServer>
    <handlers>
      <add name="httpplatformhandler" path="*" verb="*" modules="httpPlatformHandler" resourceType="Unspecified" />
    </handlers>
    <httpPlatform processPath="d:\home\site\kestrel.cmd" arguments="" stdoutLogEnabled="true" stdoutLogFile="d:\home\site\logs\stdout.log"></httpPlatform>
  </system.webServer>
</configuration>

Now browser shows:

When I run site with new web.config in local IIS then browser shows loading forever. Windows event logs populated by 2 records each second:

[DovydasNavickas]

I've spent a few days trying to run Kestrel in Azure with no luck... The sample project that @davidfowl pointed to KestrelServerOnAzure gives this in Azure:

The specified CGI application encountered an error and the server terminated the process.

[davidfowl]

When I run site with new web.config in local IIS then browser shows loading forever. Windows event logs populated by 2 records each second:

I assume you have a kestrel.cmd in d:\home\site\kestrel.cmd and a log file at d:\home\site\logs\stdout.log

[anfomin]

@davidfowl yes, I've starting file d:\home\site\kestrel.cmd and tried to create empty d:\home\site\logs\stdout.log but this does not help.

[ph1ll]

Is Windows Authentication currently supported using HttpPlatformHandler forwarding to Kestrel?

[jruckert]

I've had some luck (well got to the next problem) with this. I installed ProcMon on the server to see what was going on.

A couple of points:

<httpPlatform processPath="e:\webroot\manage\web.cmd" arguments="" stdoutLogEnabled="true" stdoutLogFile="..\stdout.log">
 </httpPlatform>

Make processPath the full path, however stdoutLogFile must be relative (i noticed that if you use the full path say:

e:\webroot\manage\logs\stdout.log, it was trying to write to:

e:\webroot\manage\logs\stdout.log\e:\webroot\manage\logs\stdout.log

On your log directory, i would recommend enabling "everyone" write access (note this is probably note required, i just was trying everything under the sun).

Now i'm at the stage of the web.cmd file having an issue, but at least i know its trying to do something.

In the log file i'm now getting:

Hosting environment: Production Now listening on: http://localhost:5000 Now listening on: http://localhost:22948 Application started. Press Ctrl+C to shut down.

Still no rendering through IIS though, but at least its something.

[davidfowl]

@ph1ll The new version will support it. It will be released in sync with beta8.

[jruckert]

I can confirm that this will work with the current version of HttpHandler (without Windows Authentication), just got it rendering through IIS

[davidfowl]

@jruckert

Make processPath the full path, however stdoutLogFile must be relative (i noticed that if you use the full path say:

The 1.0 version of the module only supports full paths. As for the stdoutLogFile take a look at the sample here:

http://www.iis.net/learn/extensions/httpplatformhandler/httpplatformhandler-configuration-reference

Optional string attribute.

Specifies the relative OR absolute file path for which stdout and stderr from the process specified in processPath will be logged. Relative paths are relative to the root of the site. When using absolute paths, please use fully qualified windows path like \?\c:\logfiles OR \UNC\logfiles.

The default value is httpplatform-stdout.

[anfomin]

@jruckert yes, with full path to .cmd file and relative path to .log file server begins to load. But log files contains errors:

System.InvalidOperationException: Unable to load libuv.
   at Microsoft.AspNet.Server.Kestrel.Networking.Libuv.Load(String dllToLoad)
   at Microsoft.AspNet.Server.Kestrel.KestrelEngine..ctor(ILibraryManager libraryManager, ServiceContext context)
   at Microsoft.AspNet.Server.Kestrel.ServerFactory.Start(IFeatureCollection serverFeatures, Func`2 application)
   at Microsoft.AspNet.Hosting.Internal.HostingEngine.Start()
   at Microsoft.AspNet.Hosting.Program.Main(String[] args)
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at Microsoft.Dnx.Runtime.Common.EntryPointExecutor.Execute(Assembly assembly, String[] args, IServiceProvider serviceProvider)
   at Microsoft.Dnx.ApplicationHost.Program.ExecuteMain(DefaultHost host, String applicationName, String[] args)
   at Microsoft.Dnx.ApplicationHost.Program.Main(String[] args)
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at Microsoft.Dnx.Runtime.Common.EntryPointExecutor.Execute(Assembly assembly, String[] args, IServiceProvider serviceProvider)
   at Microsoft.Dnx.Host.Bootstrapper.RunAsync(List`1 args, IRuntimeEnvironment env, String appBase, FrameworkName targetFramework)
   at Microsoft.Dnx.Host.RuntimeBootstrapper.ExecuteAsync(String[] args, BootstrapperContext bootstrapperContext)
   at Microsoft.Dnx.Host.RuntimeBootstrapper.Execute(String[] args, BootstrapperContext bootstrapperContext)

Any ideas how to resolve this error? I'm running dnx-clr-win-x86.1.0.0-beta8-15736 on Azure.

[davidfowl]

@anfomin Try updating to the latest of all of your packages. There's a bug we had where publish was failing to include the native binaries https://github.com/aspnet/dnx/issues/2858. Here's a reminder that when you use ci builds. You'll get burned :smile:

[anfomin]

@davidfowl I'm using latest packages from https://www.myget.org/gallery/aspnetvnext. May be https://www.myget.org/gallery/aspnetcidev will work?

[davidfowl]

Yep, that's even more bleeding edge. You'll definitely get something newer, but feel free to try it out.

[davidfowl]

@anfomin It's also not a bug in the package, it's a bug in dnu publish that was fixed.

[jruckert]

@davidfowl one more quick one, i have a second project that is having the following issue when running through the HttpHandler (the first project now works really well)

Hosting environment: Production Now listening on: http://localhost:10256 Now listening on: http://localhost:20955 Application started. Press Ctrl+C to shut down.

Process is terminated due to StackOverflowException.

Running from the cmd line manually works fine, should i park it and wait till the release of RC1 on the dev feed?

[davidfowl]

@janpieterz I don't think it has anything to do with the platform handler. Are the 2 applications using the same versions of dependencies? Maybe you're hitting this bug https://github.com/aspnet/Hosting/commit/520fc2b5fdee91c7bded01dbade2cfdf18ff412b?

[anfomin]

@davidfowl yes, with latest DNX and packages from https://www.myget.org/gallery/aspnetcidev site works on Azure. Thank you!

Does one support SSL (https)?

[davidfowl]

The changes that are being made to the next version of HttpPlatformHandler are as follows:

• Support for forwarding windows auth
• Support for forwarding the scheme
• Support for relative paths (in process and log file)
• Down level windows support (IIS 7.5)

There's a new middleware here (https://github.com/aspnet/IISIntegration) that takes this information from headers that IIS sends and makes it visible to the ASP.NET app in a "normal" way.

We've also built in support so that debugging in Visual Studio works by the time beta8 ships.

[anfomin]

@davidfowl there was a way to display detailed errors in Azure environment via appSettings key in web.config:

<add key="ASPNET_DETAILED_ERRORS" value="true" />

But this does not work any more for HttpPlatformHandler. Is there is new way to display detailed errors?

[davidfowl]

You should be able to set Hosting:DetailedErrors to true in the azure configuration settings without having to redeploy.

[DovydasNavickas]

@jruckert , @anfomin can you publish the project that works for you somewhere in GitHub or a zip in OneDrive?

[buraktamturk]

I don't really understand why Helios no longer have a life. Aren't inter-process communication are expensive? The application will now send the data to IIS Module (different address-spaces so data will be copied twice to RAM, unless they use shared memory between them but its unlikely in there since kestrel is a http server, and they'll likely to be wait for task-switch) then HttpPlatformHandler will send it to IIS's API while the application can directly call IIS api by using Helios wrapper (same address space)

My question is: why it is so bad to run the DNX alongside with the application in IIS Worker Process address-space? Will there any way to do it in future?

I think there will be no way run the application inside of IIS Worker Process (where you can directly call the function that HttpPlatformHandler would call) any longer without Helios.

I wonder how many developers in Microsoft agree / disagree the removal of "Helios". :/

[davidfowl]

I don't really understand why Helios no longer have a life.

Was there something in the original post that was unclear about the benefits of a unified hosting model?

My question is: why it is so bad to run the DNX alongside with the application in IIS Worker Process address-space? Will there any way to do it in future?

It's not bad and the original post explains why we're doing it.

Aren't inter-process communication are expensive?

Yes it is more expensive. We think it won't be a problem for most real world applications. Though on hello world there is a big difference.

I think there will be no way run the application inside of IIS Worker Process (where you can directly call the function that HttpPlatformHandler would call) any longer without Helios.

That's correct.

[guardrex]

We think it won't be a problem for most real world applications. Though on hello world there is a big difference.

"we think" ... "big difference" ... Scary, but It is that time of year! :ghost: :jack_o_lantern:

It would be great if you expanded the https://github.com/aspnet/benchmarks to show some figures for a real world-ish app (something that has a little network I/O latency) and the Hello World app for beta7 (Helios-IIS) vs. beta8 (HttpPlatformHandler-IIS) so that we can see what you're talking about.

[buraktamturk]

@davidfow I can understand the removal of "Helios". But I can't understand that this will be replaced by a such mechanism (the mechanism I mean here is the application will run in a separate process).

What I understand from the original post as an advantage is now the new ASP.NET will not use System.Web on the managed "IIS AppPool".

Well if it is a problem ASP.NET developers can code a new IIS AppPool mechanism (so there will be 3 of them classic, managed (for 4.6, didn't recommended any more), and super managed for ASP.NET 5 applications) and a new pipeline so the new IIS's AppPool will not use System.Web request pipeline and also can bootstrap the Application into the worker process. By implementing such thing the application and IIS Worker will be in same process and they won't need any IPC mechanism for communicate each other.

Let's take original post into consideration.

The IIS AppPool doesn't need to run any managed code (you can literally configure it to not load the CLR at all)

Yes, but this can't really be considered as an advantage. This is disadvantage. IIS AppPool will be native but the application that's started by IIS AppPool will be managed. This means the application will not run on "IIS Worker Process", (if it runs then AppPool will run managed code) and IPC stuff will be come in reality.

The existing ASP.NET Windows component does not need to be installed to run on Windows Servers

Almost nobody have problem with it.

Existing ASP.NET 4.x modules can run in IIS alongside the HttpPlatformHandler since the ASP.NET 5 process is separate

Didn't they work before since Helios injects into System.Web pipeline? This also this kills the advantage "1" since IIS's AppPool will have to run managed code (and use System.Web) for existing ASP.NET 4.x modules and kills the advantage "2" as ASP.NET windows component are needed for running them.

[davidfowl]

Yes, but this can't really be considered as an advantage. This is disadvantage. IIS AppPool will be native but the application that's started by IIS AppPool will be managed. This means the application will not run on "IIS Worker Process", (if it runs then AppPool will run managed code) and IPC stuff will be come in reality.

I actually don't think it will matter for 90% of applications. Sure there will be some configuration differences but there shouldn't be a functional difference.

Didn't they work before since Helios injects into System.Web pipeline?

Nope, they didn't work before and couldn't work. Helios short circuits the System.Web pipeline very early.

I know this is new to people (or old depending on how far back you dive into ASP.NET's history of hosting models) but for the most part, the end result will be similar. IPC is hidden within the platform handler and this model will enable some new scenarios that we'll be pursuing in the future.

[buraktamturk]

@davidfowl Why not writing a new "IIS AppPool" mechanism, there are two implementations now: classic (the native one), managed (the managed one, as far I know, that implements System.Web pipeline).

The new one can be named as "managed for ASP.NET 5 applications", also they do not have to support ASP.NET 4.6 modules, they can implement a new optimised request pipeline and bootstrap the application in a right way, and they may directly implement HttpAbstractions that ASP.NET 5 uses (not as Helios since as far i understand from these post Helios makes some hacky stuff).

[davidfowl]

Why not writing a new "IIS AppPool" mechanism, there are two implementations now: classic (the native one), managed (the managed one, as far I know, that implements System.Web pipeline).

Not sure what you mean. IIS + System.Web already exists today and we're not writing another version of this.

The new one can be named as "managed for ASP.NET 5 applications", also they do not have to support ASP.NET 4.6 modules, they can implement a new optimised request pipeline and bootstrap the application in a right way, and they may directly implement HttpAbstractions that ASP.NET 5 uses (not as Helios since as far i understand from these post Helios makes some hacky stuff).

That's what we get with HttpPlatformHandler but instead of being a new module that we wrote that runs in process, it's one that already exists that we can take advantage of. Today we've chosen to stick with an existing module rather than write a new one from scratch. Maybe we'll write one in the future but for now, this is the current direction.

[davidfowl]

@GuardRex we'll publish hello world results. Choosing specific words out of a quote can also be dangerous! I'm hesitant to say we're 100% sure because the truth is we just don't know yet for sure. What I do know is that normal applications don't really do 50,000 RPS, in fact very large ones do less then 1000 (unless you're Facebook or Twitter). So when I say applications won't see a difference that's what I mean.

[benaadams]

I do know is that normal applications don't really do 50,000 RPS, in fact very large ones do less then 1000

A recent contextual item 118,200 Glastonbury 2016: festival tickets just went on sale and sold out in 30 minutes (41.84 million U.S. dollars in sales); which seems quite staggering. However 118200 items over 30 minutes, is only an average of 66 a second... (extrapolating to 5,673,600 sales a day)

In likelyhood if you needed higher speeds you be probably using more than on server anyway? Scaling out is easier and more resilient.

[borgdylan]

When using the platform handler on azure, I get exceptions telling me the IRuntimeEnvironment could not be determined. How can I fix this. All requests are being proxied over (as I used HTTP_PLATFORM_PORT to give a value to the asp.net 5 server).

[ghost]

I tried the solutions from @jruckert and @anfomin but I keep getting the following message when I visit the website on Azure..

The specified CGI application encountered an error and the server terminated the process.

The stdout logs are all empty, 0 kb. The event log however throws me this error a few hundred times..

Process '0' failed to start. Port = 26343, Error Code = '-2147024894'.

The httpHandler of my web.config is the following:

<httpPlatform processPath="D:\home\site\approot\kestrel.cmd" arguments="" stdoutLogEnabled="true" stdoutLogFile="..\logs\stdout.log"></httpPlatform>

Note: I tried both the kestrel.cmd and web.cmd as defined in the project.json..

"commands": {
    "web": "Microsoft.AspNet.Hosting --server Microsoft.AspNet.Server.Kestrel --server.urls http://localhost:5000",
    "kestrel": "Microsoft.AspNet.Server.Kestrel --server.urls http://localhost:5000",
    "ef": "EntityFramework.Commands"
  },

[DovydasNavickas]

I will post how to solve this tomorrow (UTC+3). Or Microsoft guys will have already released beta8.

[davidfowl]

@Niekess Try creating a new project with beta8 tooling.

[ghost]

@davidfowl Didn't noticed you guys released the tooling. Will try now straight away and report back.

[DovydasNavickas]

Nice!! Didn't see that beta8 is available already. Thanks @davidfowl!

@Niekess fyi blog post about it can be found here: http://blogs.msdn.com/b/webdev/archive/2015/10/15/announcing-availability-of-asp-net-5-beta8.aspx

[guardrex]

Stuck ... close I think ... but stuck. Did the following:

1. Installed HttpPlatformHandler v1.2 on the VM. Restarted the VM (but I wouldn't think that should matter).
2. Changed AppPool Basic Setting for the app to "No Managed Code"
3. Updated DNVM and VS 2015 with beta8 tooling updates. Restarted the PC.
4. Used DNVM to install beta8 runtime and confirmed active and default runtimes set properly
5. Removed wwwroot > bin > AspNetLoader.dll from project
6. Added the httpPlatformHandler handler bits to wwwroot > web.config in project
7. Dropped Microsoft.AspNet.Server.IIS in favor of Microsoft.AspNet.Server.Kestrel
8. Upgraded all packages from beta7 to beta8 and restored packages
9. Added web command for hosting to project.json with correct localhost and IIS endpoint addresses
10. Also added the kestrel command (but I don't think its strictly necessary here)
11. Updated Publish profile to use correct beta8 runtime
12. Updated global.json to use correct runtime
13. Compiled and fixed two small breaking change exceptions for beta8
14. Published the app with MS Deploy (was working with beta7)

Locally, I can run the app with both the web and kestrel commands, but triggering IIS Express results in "ERR_CONNECTION_REFUSED."

With the VM, the application is unresponsive. It can't be browsed locally on the VM nor from here over the Internet.

This popped up in the log on the VM:

Microsoft.AspNet.Server.Kestrel.Networking.UvException: Error -4092 EACCES permission denied
   at Microsoft.AspNet.Server.Kestrel.Networking.Libuv.Check(Int32 statusCode)
   at Microsoft.AspNet.Server.Kestrel.Networking.UvTcpHandle.Bind(String host, Int32 port)
   at Microsoft.AspNet.Server.Kestrel.Http.TcpListener.CreateListenSocket(String host, Int32 port)
   at Microsoft.AspNet.Server.Kestrel.Http.Listener.<>c__DisplayClass5_0.<StartAsync>b__0(Object _)

Any idears what I missed or misconfigured???

[benaadams]

Permissions? Probably need to do a netsh http add urlacl ... https://msdn.microsoft.com/en-us/library/windows/desktop/cc307223(v=vs.85).aspx

[guardrex]

@benaadams Seems strange. I've never had to run that command in 8 years of working with IIS. This was an existing app (beta7) running in IIS on that VM on that endpoint address and port.

[benaadams]

kestrel clashing with IIS then? Same port?

[guardrex]

It's the only app with that port assigned. Let me see what happens when I remove the port binding in IIS. brb

[davidfowl]

@GuardRex What's in your web command?

[guardrex]

"web": "Microsoft.AspNet.Hosting --server Microsoft.AspNet.Server.Kestrel --server.urls http://localhost:56857;http://www.xxxxxx.com:8001"

[davidfowl]

Remove all --server.urls from the application.

[guardrex]

Ok ... better ... it's running in IIS Express now. Will try on the VM next.

[jruckert]

@GuardRex where was the HttpHandler v1.2 download package? I can only find v1.0 as a independent install.