Azure Web App: Environment variables provided in the arguments attribute aren't interpreted anymore

[Tratcher]

From @toburger on June 28, 2017 8:22

I use the following library to host my web application: https://github.com/SuaveIO/Suave.IIS

The hosting port gets provided via:
arguments="%ASPNETCORE_PORT%"

Since yesterday everything worked normally. The port was parsed and the app worked flawlessly.
But suddenly I've got the dreaded 502 gateway error.

After some debugging I found the reason of the error:
The environment variable doesn't get interpreted anymore. My program receives the plain "%ASPNETCORE_PORT%" string and not the value of the environment variable.

My workaround is to read the environment variable in the application itselft, but I wonder why the behavior has changed and why this is happening exclusively on Azure. I think the aspNetCore module was updated, but I can't find any information about this breaking change.

Copied from original issue: aspnet/IISIntegration#389

[Tratcher]

A new version of AspNetCoreModule is being deployed to Azure.

@pan-wang was there a change to environment variable resolution in the arguments?

    <aspNetCore
	forwardWindowsAuthToken="true"
        startupTimeLimit="20"
        stdoutLogEnabled="true"
        stdoutLogFile="myiiswebname.log"
	processPath="C:\inetpub\wwwroot\myiiswebname\myiiswebname.exe"
        arguments="%ASPNETCORE_PORT% &quot;myiiswebname&quot;">
	<!-- if running on http://localhost/myiiswebname -->
    </aspNetCore>

[pan-wang]

This is by design. As we discussed, ASPNETCORE_PORT is a reserved environment variable and should only be set by ANCM.

…

________________________________ From: Chris Ross <notifications@github.com> Sent: Wednesday, June 28, 2017 7:09:52 AM To: aspnet/AspNetCoreModule Cc: pan-wang; Mention Subject: Re: [aspnet/AspNetCoreModule] Azure Web App: Environment variables provided in the arguments attribute aren't interpreted anymore (#117) A new version of AspNetCoreModule is being deployed to Azure. @pan-wang<https://github.com/pan-wang> was there a change to environment variable resolution in the arguments? <aspNetCore forwardWindowsAuthToken="true" startupTimeLimit="20" stdoutLogEnabled="true" stdoutLogFile="myiiswebname.log" processPath="C:\inetpub\wwwroot\myiiswebname\myiiswebname.exe" arguments="%ASPNETCORE_PORT% &quot;myiiswebname&quot;"> <!-- if running on http://localhost/myiiswebname --> </aspNetCore> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#117 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ARVK2xSnj6cpv7toU1Bp1JSkobEqyizqks5sIjSAgaJpZM4OH0Pl>.

[Tratcher]

Did it previously pick up the value set by ANCM, or only external values?

[pan-wang]

I looked at code. It is a regression from the code refactoring.

[pan-wang]

I think the right coding pattern for customer should be reading the environment variables from the application instead of using commandline parameters

[Tratcher]

@toburger Out of curiosity what were you doing with the ASPNETCORE_PORT value when passed in via command line? When running behind ANCM, IISIntegration reads this value for you and sets up Kestrel.

[toburger]

I'm not the author of the library but I think the intention was to not rely on some global state which might or might not be set and instead pass the port explicitly to the self hosting program.
This also allows the caller of the program to provide some custom port if needed.

[Tratcher]

There's no need. We manage that state on behalf of the app via UseIISIntegration. This even overrides settings provided directly to Kestrel, so they're likely doing redundant work.

Taking the port as a command line parameter when running the app elsewhere is fine. I don't think you need to change anything in SuavelO.

[Tratcher]

Wait, SuaveIO doesn't use any ASP.NET Core packages? It's a completely independent framework running behind AspNetCoreModule?

AspNetCoreModule is not supported as a standalone component, it's part of the ASP.NET Core framework. We often coordinate changes between the various components that may break 3rd parties that get out of sync.

[davidfowl]

Right, Suave should depend on the http platform handler.

[Dzoukr]

Thanks @davidfowl, but http platform handler is deprecated, right? I saw this announcement - aspnet/Announcements#164

Or there is plan to have them both side-by-side?

Thanks for any hint.

[Tratcher]

@Dzoukr ASP.NET Core stopped using it, but other things still do.