[HttpPlatformHandler]: Publish changes to web.config for IIS based hosting

[davidfowl]

We need to change the web.config that publish generates to be based on httpplatformhandler based hosting.

Here's what a typical web.config looks like today for Helios:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <appSettings>
    <add key="bootstrapper-version" value="1.0.0-beta7" />
    <add key="runtime-path" value="..\approot\runtimes" />
    <add key="dnx-version" value="1.0.0-beta7" />
    <add key="dnx-clr" value="clr" />
    <add key="dnx-app-base" value="..\approot\src\meetup" />
  </appSettings>
  <system.web>
    <httpRuntime targetFramework="4.6" />
  </system.web>
</configuration>

Here's what the new web.config (tentative) would look like:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <add name="httpplatformhandler" path="*" verb="*" modules="httpPlatformHandler" resourceType="Unspecified" />
    </handlers>
    <httpPlatform processPath="..\web.cmd"
                  arguments="" 
                  stdoutLogEnabled="true" 
                  stdoutLogFile="..\stdout.tlog">
    </httpPlatform>
  </system.webServer>
</configuration>

The .cmd file also has to be updated to take variable into account:

Few notes:

• We're waiting on the httpplatformhandler to support relative paths. This will make the web.config alot more portable (and self contained).
• We need to know which command to put the relative path to in web.config, this might be an option.
• Notice we don't need any of the old variables since all of that knowledge is encapsulated in the .cmd file e.g.

@"%~dp0approot\runtimes\dnx-clr-win-x64.1.0.0-beta8-15594\bin\dnx.exe" --appbase "%~dp0approot\packages\WebApplication74\1.0.0\root" Microsoft.Dnx.ApplicationHost --configuration Debug web %*

• Dnx version selection (based on what was passed into publish --runtime switch)
• The appbase, configuration etc

We want to make this work with a global cache if it has a the version of the dnx installed. The .cmd file could be updated to detect the versions of runtime in DNX_HOME. This would look like:

SET DNX_FOLDER=dnx-clr-win-x64.1.0.0-beta8-15594

"HOME_DNX=%DNX_HOME%\runtimes\%DNX_FOLDER%\bin\dnx.exe"
"LOCAL_DNX="%~dp0approot\runtimes\%DNX_FOLDER%\bin\dnx.exe"

IF EXIST %HOME_DNX% (
"DNX_PATH=%HOME_DNX%"
) ELSE IF EXISTS %LOCAL_DNX% (
"DNX_PATH=%LOCAL_DNX%"
)
ELSE (
DNX_PATH=dnx
)

@%DNX_PATH% --appbase "%~dp0approot\packages\WebApplication74\1.0.0\root" Microsoft.Dnx.ApplicationHost --configuration Debug web %*

I didn't test the above but the gist is to test if the DNX_HOME/runtime exists over the local one. This only applies if the full version was specified. Otherwise we'll use the one on the path. We could consider always some variable that would be settable from the outside to control aspects of running.

Features of helios:

• Exclude the runtime and have the layout still be found via version
• Change the bitness without redeploying if both runtimes are "installed"

[borgdylan]

Wren the switch to the http platform handler happens, would newly published projects work on the versions of IIS that Helios runs on today?

[davidfowl]

No Helios will be dropped completely

[borgdylan]

My question was, would the new technique work on IIS 8.1+ even if it means that I have to make the process path absolute by hand?

[davidfowl]

The module needs to be installed on IIS severs that want to run ASP.NET 5

[guardrex]

Will these changes lead to being able to run .NET 5 without a .NET 4.x framework on the server?

[davidfowl]

.NET 5 doesn't exist, you mean .NET Core? Yes. You'll install the HttpPlatformHandler and you'll be able to use it without installing .NET or ASP.NET for that matter on the server.

[borgdylan]

@davidfowl so the module is available as an MSI/EXE/MSU?

[davidfowl]

That's what I linked to

[guardrex]

Rats! .NET 4.x is so woven into WS2012/WS2012R2 that it's impossible to live without it (especially in an Azure VM situation). The Core Team Blog says, 'Don't even think about it!'

http://blogs.technet.com/b/askcore/archive/2014/04/24/removing-net-framework-4-5-4-5-1-removes-windows-2012-2012r2-ui-and-other-features.aspx

[marcind]

To round out the story of loading the runtime from the cache, it would be great to make it easier to use dnvm to install dnx runtimes into a machine-wide location.
The reason for this is when the app runs in IIS it will run in the context of a specific identity (tied to the app pool) which might not have the dnx installed (i.e. DNX_HOME and PATH set properly).

[davidfowl]

@marcind That's already been done in the latest dnvm. There's a global install location now and it is appended to DNX_HOME.

[marcind]

@davidfowl will using -Global and -Persistent apply to the whole system or just the user running the command?

[davidfowl]

Whole system.

[marcind]

Hmm, can't see [EnvironmentVariableTarget]::Machine being used anywhere in the dnvm.ps1 source. Only [EnvironmentVariableTarget]::User.

[analogrelay]

We don't support -Persistent at the machine level. You can install to the machine location but can't modify the global PATH in dnvm right now.

[marcind]

So I havn't thought about the new process model when hosting in IIS, but assuming you're running multiple app pools with different identities, setting the machine location would be necessary to make the global dnx location work.

[analogrelay]

If you're running multiple app pools, do you really want them all to share the DNX version? We didn't find much use case for dnvm use -persistent because generally you want an app to be able to control it's DNX version, but let us know if we're wrong there.

There is definitely a use for a globally-defined DNX_HOME defining search paths, and I think we've got that. The batch file used to bootstrap DNX in this scenario would work by searching those paths for the requested version, so you can dnvm install -g and then it should "Just Work" :)

[analogrelay]

FYI, it does look like the DNVM install script does not set DNX_HOME globally so that might be a gap in our strategy there. I believe the MSI does set that variable though.

[davidfowl]

Fail! 😀

[analogrelay]

I believe it was removed because it means DNVM setup has to be run elevated (at least it does in order for this to work). We can review that decision, it's super easy to put back in.

[marcind]

I don't want all the app pools to share the DNX version. I want all the app pools to share the DNX runtime cache location. If I happen to have multiple apps targeting the same DNX version, then those binaries should be loaded from the same place.

I agree that dnvm use wouldn't be of much use when configuring a deployment target, because I want the application to explicitly define which runtime it's targeting. The host machine should have no say in that. dnvm install -g is much useful in that regard.

Here's how I want to script the deployment process for my apps

1. My CI packages up just the application binaries and artifacts (no runtime, no library packages, but those references are explicitly declared in project.json or web.config or whatever) using dnu publish
2. I get that package onto the target deployment box.
3. I run dnvm install -g [app target runtime], which noops if the global cache already has the runtime
4. I run dnu restore on the app to suck up missing library packags. These use a global package cache so I don't have to download the same packages over and over again.
5. I point IIS at the app and run it, which might be using a different Identity, but I want it to still be able to resolve the runtime from the global runtime cache.

In general I want a model where a script driver pulls all the application artifacts onto the deployment host, based on what the application needs. I don't want to have to upload MSIs or whatever. If you want to wrap that script in an MSI, I guess that might be fine, but seems unnecessary. (do you get an ARP entry for every runtime? I don't care about that).

I'm fine running dnvm elevated to get things bootstrapped.

[analogrelay]

Yeah, that should be fine. We're absolutely targeting that scenario. The script that is used to launch your app would search DNX_HOME to find the desired runtime, so as long as we ensure that the global install directory is on DNX_HOME we should be set. I'll file a bug on dnvm to look at this.

[analogrelay]

aspnet/dnvm#439

[analogrelay]

FYI, you'd just be installing the one MSI (the DNVM MSI), not an MSI per runtime. I agree that we should have an MSI-less option though.

[davidfowl]

Need to put script files in approot since webdeploy can't see them.

[muratg]

@davidfowl When is the cmd file change coming in? 👀

[muratg]

@davidfowl this bug good to close now?