AspNetCore Module fails to start

[flagbug]

I'm creating this issue based on the following Twitter discussion: https://twitter.com/flagbug/status/733313828889481217

I've deployed my Asp.Net Core RC2 app to Azure App Services via Git deploy, and the deploy work fine, but the AspNetCore module doesn't seem to be able to start:

I'll try creating a sample project to reproduce this issue, but this will take some time, maybe someone else has an idea what's happening in the meantime

[davidebbo]

Can you share your web app name, either directly or indirectly? This will help us investigate. Thanks!

[flagbug]

@davidebbo Sure, I've just created a fresh deployment at http://tiny-tutors-alexandria-aspnetrc2test.azurewebsites.net/ where I'm also seeing this issue

[davidebbo]

Interesting. So in your case, you end up with a .exe in wwwroot, and web.config pointing to it:

<aspNetCore processPath=".\Alexandria.exe" arguments="" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="false" />

While with my test app (https://github.com/davidebbo-test/AspNetCoreRC2VS), I end up with no .exe, and config instead uses dotnet.exe against an assembly:

<aspNetCore processPath="dotnet" arguments=".\AspNetCoreRC2.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="false" />

The whole RC2 model is still new to me, so I'll need those guys to help me understand the difference. @davidfowl when do we end up with one model vs the other?

[davidfowl]

@troydai we need a standalone test case.
/cc @moozzyk for ideas

[flagbug]

@davidebbo This may be because I'm creating a standalone Asp.Net Core application, so I don't have to install .NET Core on the target machine, and instead specified the Runtime Identifiers

Maybe Kudu doesn't work with standalone apps yet?

[davidfowl]

@flagbug is your repository public? Are you setting the urls manually or using the default?

[flagbug]

@davidfowl Nope, sorry, it's private :/ Which URLs are you talking about exactly?

[davidfowl]

What does your startup.cs look like

[flagbug]

@davidfowl https://gist.github.com/flagbug/b59d68c95a4e2f4cbd350590f6c283eb

[davidfowl]

Ah need Program.cs not Startup.cs 😄

[davidfowl]

Hmm, that looks fine.

[troydai]

Standalone case here: https://github.com/troydai/KuduSample05/blob/master/src/SampleApp05/project.json

Yes?

[davidebbo]

But we established yesterday that this sample runs fine in Azure Web Apps (after we fixed the bitness). So there must be some difference.

[flagbug]

Aha! Process '11452' started successfully and is listening on port '22716'.

Seems like it works if I remove the standalone feature. Still getting a 500 Internal Server Error. An error occurred while starting the application., but this seems to be in the application now!

[flagbug]

These were the runtimes I was specifying btw:

"runtimes": {
    "win81-x64": { },
    "win8-x86": { }
  },

[troydai]

@flagbug can you try add win7-x86 to the runtime id list?

[flagbug]

@troydai I just noticed that my App Service is set as 64-bit, should I still use win7-x86, or should I rather use win7-x64?

[troydai]

@davidebbo can correct me if I'm wrong. But my understanding is that the architecture of runtime should match your AppServices's architecture, @flagbug.

[davidebbo]

Wouldn't it cause a build error though? In your sample, when you had just "win7-x64", build was failing. When we added "win7-x86", it built and ran. But for @flagbug everything builds. Just blows up at runtime.

Still worth a try to add those runtimes in project.json. @flagbug give it a shot!

[flagbug]

@troydai Well, that's a bit hard to know with Azure App Services, I have no idea on which OS Version my App is running on, I only know the bitness 😄

[davidebbo]

It's Server 2012 (not R2), which I think maps to Win7.

[moozzyk]

If the process starts and you get 500 then I would recommend turning on logging. If you use web deploy/publish-iis remove the stdoutLogFile attribute or set the value to \\?\%home%\LogFiles and set stdoutLogEnabled to true. You should see log file which should tell you what happened.
I have not had a chance to try a portable app (i.e. dll) because dotnet runtime was not installed until yesterday. Standalone (.exe) worked when I tried it last week.

[davidebbo]

@flagbug I took the liberty of changing that in your test site:

<aspNetCore processPath="dotnet" arguments=".\Alexandria.dll" stdoutLogEnabled="true" stdoutLogFile="\\?\%home%\LogFiles" forwardWindowsAuthToken="false" />

But I'm not seeing any interesting logs generated after hitting the site.

[snobu]

Windows Server 2012 maps to Windows 8

https://msdn.microsoft.com/en-us/library/windows/desktop/ms724832(v=vs.85).aspx

[davidebbo]

@snobu thanks! Well, so it may not be the root of the issue after all. And since logging is not working, it's hard to diagnose :(

[hoetz]

FWIW I redeployed my RC2 site today and now it fails as well.
It ran fine the last couple of days, only css changes and it runs fine locally.
I created a completely new site (the old still had RC1 stuff in it) deployed from github again and still getting "not allowed to list contents" error.
Feel free to look at my site https://3dscom.azurewebsites.net
github source: https://github.com/hoetz/3dshootercom/tree/master/src/Web

UPDATE: After some tweaks to my project.json it works for me!

[davidebbo]

@hoetz please see Test your ASP.NET Core repo locally.

Closing this issue for now as I don't think there is a Kudu issue here. If someone still has an issue after successfully going through the steps locally, we can re-open (or maybe start clean issue).