x64 version of dotnet when x64 platform is set in portal

In Azure portal, I set platform to x64 in the application settings. Then added "platform": "x64" under “buildOptions” in aspnet-core app’s project.json file (along with win7-x64 RID). Our app is targeting SDK "1.0.0-preview2-003121". After the deployment, I received HTTP Error 502.5 - Process Failure. On Kudu’s CMD, I ran the executable under d:\home\wwwroot and received:

An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)

searched this error on related repos, which led me to: https://github.com/aspnet/KestrelHttpServer/issues/1118 suggesting that we need to have dotnet.exe x64 in PATH before x86. Unfortunately, we don’t have x64 bit available on Azure websites (dir "D:\Program Files" vs dir "D:\Program Files (x86)").

To overcome this shortcoming, I have installed dotnet x64 at D:\home\site\deployments\tools like:

cd D:\home\site\deployments\tools

curl -O https://dotnetcli.azureedge.net/dotnet/Sdk/1.0.0-preview2-003121/dotnet-dev-win-x64.1.0.0-preview2-003121.zip

unzip dotnet-dev-win-x64.1.0.0-preview2-003121.zip

It would be very much appreciated if, in addition to x86 dontet-cli, we receive x64 counterpart installed (with all the SDK versions available for x86) out of the box, so we don’t need to install in every App Service (we have seven dedicated services for the affected app). Also, if possible, would be nice if this transition in PATH (dotnet-x64 before dotnet-x86 and viceversa) happen when we change the bitness in portal.

Thanks.

[am11]

It’s crazy

That it is. We get OOTB installation of x86 & x64 variants when it comes to Ruby, Python, node.js and many other frameworks, but for .NET Core it’s only x86. If there is an issue in having both on the system, then it should be only x64 instead or user should have a choice. In Azure Portal -> AppService -> Settings, if we change the architecture to x64, it has no impact on .NET Core (dotnet-cli remains x86)…

workaround

My initial workaround (see top comment) was do download dotnet-sdk in x64, and put it in PATH as per Kudu documentation; D:\home\site\deployments\tools directory. The direct download links to the SDK are available in release notes, f.ex: https://github.com/dotnet/core/blob/master/release-notes/download-archives/2.0.3.md

[Oceanswave]

Came across this trying to run a .net core Azure Function with x64 dependencies. Thanks to OP for describing a workaround, but the fact that this is still an issue is aggravating.