locked
.Net Core vs MVC RRS feed

  • Question

  • Hi.

    When I'm deploying a ASP.Net Core web site with .Net Core to an Azure App service I get the error:

    You do not have permission to view this directory or page.

    Using a ASP.Net MVC web site deployed to the into same App Service works fine. Both integrate with Azure AD and I couldn't see that the Core version is missing something in the deployment. I'm using VS 2015 Update 3 (14.0.25431.01) to deploy both of them. What could be the reason for this behaviour?

    Tuesday, November 15, 2016 3:11 PM

Answers

  • Ok, so it could be that the issue is related to having App Service Authentication turned on. As a test, have you tried turning it off to see if that fixes it?
    • Marked as answer by AlexanderEsser Tuesday, November 22, 2016 8:53 AM
    Monday, November 21, 2016 10:58 PM

All replies

  • Can you check using Kudu Console whether you have a web.config deployed to d:\home\site\wwwroot?
    Tuesday, November 15, 2016 3:52 PM
  • Yes, there's a web.config in wwwroot containing:

      <system.webServer>
        <handlers>
          <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
        </handlers>
        <aspNetCore processPath="dotnet" arguments=".\CustomerPortal.WebUi.dll" stdoutLogEnabled="false" stdoutLogFile="\\?\%home%\LogFiles\stdout" forwardWindowsAuthToken="false" />
      </system.webServer>
    </configuration>


    Wednesday, November 16, 2016 8:45 AM
  • Can you share your web app name, either directly or indirectly? This will help us investigate.

    thanks,
    David

    Wednesday, November 16, 2016 4:15 PM
  • It's some-customerportal.azurewebsites.net
    Thursday, November 17, 2016 3:56 PM
  • The site has authentication enabled, so I can't easily make requests to it.

    But looking at the files in your wwwroot, I notice there is a global.asax, which is never used for Core apps. It may be a result of first deploying a non-Core app and then a core app on top of it, leaving you with a mix of files. I suggest trying to wipe out wwwroot and then republishing the Core app, so you get a clean deployment.

    If that doesn't help, also try to turn on stdoutLogEnabled in the web.config, and then look for logs in the d:\home\LogFiles folder.

    David

    Thursday, November 17, 2016 6:21 PM
  • There seems to be an issue calling Kestrel:
    Unable to bind to http://localhost:23521 on the IPv6 loopback interface.
    System.AggregateException: One or more errors occurred. (Error -4089 EAFNOSUPPORT address family not supported) ---> Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.UvException: Error -4089 EAFNOSUPPORT address family not supported

    Is that something that needs to be fixed in the setup of the Azure App Service (which I don't control), or is it something I can fix in the source code?

    Friday, November 18, 2016 2:50 PM
  • This EAFNOSUPPORT error is actually a harmless (but annoying) warning, that happens in all Kestrel apps on App Service, even if they are healthy. So it is a red herring here, and not related to your issue.

    Did you try the clean up step I suggested above?

    If that doesn't help, any chance you can share a repo (see wiki) that would help us repro this issue in a test app? Thanks!

    Friday, November 18, 2016 7:34 PM
  • I did try to delete everything and it didn't help.

    The code is just the standard code created by the wizard in VS 2015 Update 3. I created a similar project against my MSDN Azure account, using my Azure AD, and it worked out of the box. The difference in the project here is that I'm using our corporate Azure account and AD.

    When I look at the network traffic I can see that the "MSDN" version runs the request to ...azurewebsites.net/signin-oidc with status 302 while the "corporate" version returns 403. Does that give any hint on what might be wrong?

    Monday, November 21, 2016 11:20 AM
  • Ok, so it could be that the issue is related to having App Service Authentication turned on. As a test, have you tried turning it off to see if that fixes it?
    • Marked as answer by AlexanderEsser Tuesday, November 22, 2016 8:53 AM
    Monday, November 21, 2016 10:58 PM
  • Yes, that seems to work :). So it isn't necessary to set the Authentication explicitly in the Portal.
    Tuesday, November 22, 2016 8:53 AM