Web App Service for Net Core 3.1 is Faulted

Daniel 1

I’ve been trying to publish a net core 3.1 app for two days trying to get it to run on Azure. Getting logs is somewhat easy except getting the container log is just not documented. It gives a link telling you how to turn it on but it doesn't actually tell you how to turn it on. Though it seems this issue not something I have control over.
From the beginning. When creating a new App Service I can choose between Windows or Linux UNLESS I choose the .Net Core 3.1 runtime, then it's Linux only. So far in two days I’ve been unsuccessful deploying my app. So I decided to create a brand new .Net Core 3.1 MVC app from a Visual Studio template so it's just a blank shell. Published it via Visual Studio to Azure and chose to create all new everything through the wizard. App still fails and this log here is what I'm getting, https://1drv.ms/t/s!AlnGeQSYLUVarbBjlchnEgCXwPcbUg which is going over some Apache failure.

Here's what's confusing. I've already had a .Net Core web app published a few years ago on a Windows App Service and the version of that app is actually 3.1, so I created a new app service in Azure, chose Windows with .Net Core 3.0 as if I choose 3.1 it removes Windows as a choice and selects Linux. So choosing 3.0 so I can select windows, so with this new Windows App Service I tried publishing the .Net Core 3.1 app and low and behold, it works.

Windows containers work yet we can't choose 3.1, Linux App Services don't work yet that’s the only choice for 3.1. I reached out to Azure Support on twitter and they told me to post here and give them the link.

How does this get reversed and corrected?

ajkuma 22,521 Reputation points Microsoft Employee

2020-02-24T19:15:56.817+00:00

Daniel, Welcome to Microsoft Q&A! Thanks for posting this question.
I understand the frustration with this problem, apologies for any inconvenience this issue may have caused.

While I check on this issue further internally, kindly checkout this discussion thread https://github.com/Azure/app-service-announcements-discussions/issues/129 for .NET Core 3.1 Availability on App Service. If feasible & your requirement fits, you may continue to host on App Service -Windows Docker Container.

.Also, as mentioned in this document -"NET Core 3.1.2 is being deployed to Azure App Services and the deployment is expected to complete later in February 2020."

Thanks for your patience & co-operation.
Daniel 1 Reputation point

2020-02-24T20:13:48.633+00:00

Yea I've read through the whole thing already. Two days spent trying to solve this. 3.1 is on Linux but as you can see in the logs I shared there's an issue that isn't anything I have control over.

Also we can't choose Windows containers (non docker) to use with 3.1 yet those are the only ones that can run 3.1 apparently. This is the NON docker Windows app service.

As explained above, windows works when it's not supposed to or enable as a choice and Linux doesn't work when it's the only choice.

The reproduction steps should take ten minutes or less to go through.
Daniel 1 Reputation point

2020-02-25T02:17:29.923+00:00

Can't even post a comment.
Daniel 1 Reputation point

2020-02-25T02:17:47.437+00:00

This is just a miserable experince. After I confirmed that I could create a Windows .Net Core 3.0 app service and deploy my app using Visual Studio publishing directly to Azure. I then try to hookup my Azure Dev Ops pipeline and release which is just incredibly difficult with the new YAML whatever, just breaks everything and adding the .Net Core tasks don't actually lead to a drop that the release looks for. Finally got something deployed but the app still won't run. So I tried publishing my app to the Windows App Service like I know works and I get a publish error. After digging and digging I find that Visual Studio publish is looking for some AppOffline.html file. So idk what's going on here but Seems like these services are just way out of sync and they aren't working with each other. I'm just sick frustrated.
Daniel 1 Reputation point

2020-02-25T02:17:59.747+00:00

(2/24/2020 9:08:39 PM) An error occurred when the request was processed on the remote computer.
Could not find file 'D:\home\site\wwwroot\App_Offline.htm'.
Daniel 1 Reputation point

2020-02-25T02:39:16.287+00:00

So I published my app using Visual Studio to another new WIndows App Service 3.0 and it works. The app uses Azure Key Vault and an SQL Database on Azure, all secrets and keys come from the key vault. The app works when publishing from Visual Studio.

In Azure Dev Ops I used the classic editor and got a build pipeline plus release to deploy as before with the YAML except now I'm getting much more logs this time within Azure when I turn on application logging. Which I'll post next because I have no idea what it means. And why would publishing from Visual Studio work but publishing the same exact app, code base, whatever, from Azure Dev ops results in this very frustrating and aggravating situation?
Daniel 1 Reputation point

2020-02-25T02:40:06.07+00:00

HTTP Error 500.30 - Internal Server Error The page cannot be displayed because an internal server error has occurred. Most likely causes: IIS received the request; however, an internal error occurred during the processing of the request. The root cause of this error depends on which module handles the request and what was happening in the worker process when this error occurred. IIS was not able to access the web.config file for the Web site or application. This can occur if the NTFS permissions are set incorrectly. IIS was not able to process configuration for the Web site or application. The authenticated user does not have permission to use this DLL. The request is mapped to a managed handler but the .NET Extensibility Feature is not installed. Things you can try: Ensure that the NTFS permissions for the web.config file are correct and allow access to the Web server's machine account. Check the event logs to see if any additional information was logged.

Continued -->
Daniel 1 Reputation point

2020-02-25T02:40:15.187+00:00

Verify the permissions for the DLL. Install the .NET Extensibility feature if the request is mapped to a managed handler.
ajkuma 22,521 Reputation points Microsoft Employee

2020-02-25T16:44:50.157+00:00

By default, Kudu executes the build steps for your .Net application (dotnet build). For Azure DevOps build scenario, then the Kudu build is unnecessary. To disable the Kudu build, create an app setting, SCM_DO_BUILD_DURING_DEPLOYMENT, with a value of false.

You may restart your app and then check to see if that helps.
The app_offline creation and removal is part of KuduSync.Net. It is supposedly removed after we are done with deploying bit to destination. You can opt out by setting appSettings SCM_CREATE_APP_OFFLINE=0.

Kudu Console : yourwebappname.scm.azurewebsites.net

msdeploy support an App Offline mode, which causes it to create a file called App_Offline.htm in the webroot folder (e.g. wwwroot) during the deployment.
ajkuma 22,521 Reputation points Microsoft Employee

2020-02-25T17:12:37.793+00:00

Ack! Again, I understand the frustration with this! I have tried similar repro and found same results, so I was checking on this internally with our product team to understand the latest changes.
NET Core 3.1 is still not completely available on App Service Windows in all the regions. Our product engineering team is actively working on this item and we are expecting that by end of February (just an ETA) all of App Service to have been updated with .NET Core 3.1. Please note that this timeline is just an estimate and is subject to change, depending on a myriad of factors. You may run into the error behavior your seeing since the underlying rollout is incremental.
Additionally, In Azure App Service, ANCM deploys on a separate schedule from the runtime because of its global nature.
I have relayed your feedback to the product team. Thanks for sharing your feedback.
ajkuma 22,521 Reputation points Microsoft Employee

2020-02-25T17:24:31.977+00:00

Just to highlight the difference between deployment options (VS, Local Git, GitHub, etc)- When using one of the options that go through Kudu, your sources live within the Azure WebApps and get built and deployed from within Azure WebApps.

If you connect to your site via Kudu Console (yoursite}.scm.azurewebsites.net), you will see your sources under site\repository, as well as various deployment related artifacts.
ajkuma 22,521 Reputation points Microsoft Employee

2020-02-25T17:31:58.053+00:00

Continuing from the above "comment":

When setting up continuous deployment to an Azure WebApps from Azure DevOps, things work in the following way:
•The repository lives in the Azure DevOps infrastructure.
•When you push a change via git, the VSTS build infrastructure builds your sources, and produces some deployment artifacts.
•Azure DevOps then uses WebDeploy (the same technology used by Visual Studio) to deploy the artifacts to your Azure WebApps.

Here, if you connect to your site using Kudu console, you will see the deployed files under your site\wwwroot folder, but won't see a repository folder, or any of the other things you get with Kudu. The Kudu engine is not involved at all in this scenario.
ajkuma 22,521 Reputation points Microsoft Employee

2020-02-25T17:34:02.847+00:00

I understand you have already the checked the Application Logs, to highlight more info on fetching the logs- For logs stored in the App Service file system, you could download the ZIP file in the browser at:

Kudu Console : yourwebappname.scm.azurewebsites.net

Linux/container apps: https://<app-name>.scm.azurewebsites.net/api/logs/docker/zip
Windows apps: https://<app-name>.scm.azurewebsites.net/api/dump

For Linux/container apps, the ZIP file contains console output logs for both the docker host and the docker container.

This document provides more information on that - https://learn.microsoft.com/azure/app-service/troubleshoot-diagnostic-logs#access-log-files
ajkuma 22,521 Reputation points Microsoft Employee

2020-02-25T17:53:33.397+00:00

Kindly try to -remove setting "WEBSITE_RUN_FROM_PACKAGE" in Azure appsettings. Ensure that Web Deploy is selected in DevOps (Select Deployment option).

To narrow down the issue further along with Application Event Log, you can also review the ASP.NET Core Module stdout log. Kindly take a look at this document on this topic - https://learn.microsoft.com/aspnet/core/test/troubleshoot-azure-iis?view=aspnetcore-3.1

If the issue still persist, I wish to engage with you offline further to understand some more details about the problem, have a closer look and provide a specialized assistance, please send an email to AzCommunity[at]Microsoft[dot]com referencing this thread and the Azure subscription ID, I will follow-up with you.
Again, sorry for all the trouble! Looking forward to your email.
ajkuma 22,521 Reputation points Microsoft Employee

2020-02-25T17:55:01.59+00:00

Just to highlight, you can always leverage App Service diagnostics to fetch more pointers on the issue.

To access App Service diagnostics, navigate to your App Service app in the Azure portal. In the left navigation, click on Diagnose and solve problems.
Daniel 1 Reputation point

2020-03-01T02:04:21.427+00:00

I've been doing this for years with a .Net Core app already been published since the 2.0 versions. It used to be pretty straight forward. You have a .Net Core app and you are using pipelines and releases to publish it to Azure. Select those options straight up did what it needed to do to deploy to Azure.

Currently this app I've had published for years that started as 2.* is now 3.1 and it's running on an Azure Windows Service.
Daniel 1 Reputation point

2020-03-01T02:04:56.947+00:00

This new, second app I'm trying to publish using CI/CD is also 3.1 and it runs when selecting a Windows 3.0 Service on Azure and publishing to it using Visual Studio. Trying to do it like the first app that I have where I have it set up to commit to the repo which triggers a build, then release then publishes to Azure is what fails. Even if I copy the classic pipeline from the first app or the YAML pipeline that does work from the first app to this new app which creates a release and publishes to Azure, the app doesn't run. From Visual Studio it does. I've spent a lot of time looking through all the different logs I could get ahold of and a lot of time learning and exploring the Kudo interface.
Daniel 1 Reputation point

2020-03-01T02:05:06.787+00:00

My investigation into it has me believing that this isn't an app issue. The app runs and the app works on Azure. The problem is when Azure Dev Ops is involved and all I want is to do what I've already been doing for years. Commit to a repo and have it publish a .Net Core app.

There has to be some issue going on with the above services right now. I hope someone can create a brand new .Net Core 3.1 app from Visual Studio or VS Code and put it into an Azure Dev Ops repo and then get it published to a Windows Service to confirm there is no issue or is an issue. Net Core is the driving force of Microsoft so if anything there should be one checkbox I would have to select for Azure Dev Ops to setup everything needed to publish. Just like Visual Studio does without Azure Dev Ops in the middle.
Daniel 1 Reputation point

2020-03-01T03:01:02.85+00:00

So both deploys of the same 3.1 app from Visual Studio or Azure Dev Ops produces the same deploy files, I can edit the web.config on both and enable stdout. Only necessary to enable on the Azure Dev Ops below as that's the one that fails. It says,

"The specified version of Microsoft.NetCore.App or Microsoft.AspNetCore.App was not found."

So I'm wondering what is the difference between deploying from Visual Studio then from Azure Dev Ops doing both with Web Deploy.
Daniel 1 Reputation point

2020-03-01T03:35:32.09+00:00

Another good thing to understand would be to why my original first app that was setup years ago and has been deploying since then with each new .Net Core version all the way up to now, 3.1, will deploy to a Windows Service App without any problem while this new one won't through Azure Dev Ops using the same YAML file copied over from the first one and the same release configuration and settings copied from the first one. Both 3.1. Neither of them have the packages mentioned above installed, "Microsoft.AspnetCore.App" or "Microsoft.NetCore.App" as the first one did but with each migration the uneeded packages were removed like directed by docs which are great btw. I always speak very highly of Microsoft Learn to anyone they are the industry lead by a large margin no doubt.
Daniel 1 Reputation point

2020-03-01T03:36:22.323+00:00

But neither app has these packages installed except the second (new) app is the only one failing on an Azure Dev Ops deploy with the above error displayed when "stdout" is set to true. When deployed from Visual Studio there is no problem.

I'm guessing that simply waiting for more updates to happen on the Azure side is going to be needed but still curious to why one app works and the other doesn't And why the one that doesn't works from the IDE but not from CI/CD.
ajkuma 22,521 Reputation points Microsoft Employee

2020-03-03T10:55:41.017+00:00

As highlighted above on difference in the deployment options - when setting up continuous deployment to an Azure WebApps from Azure DevOps, things work in the following way: •The repository lives in the Azure DevOps infrastructure. •When you push a change via git, the VSTS build infrastructure builds your sources, and produces some deployment artifacts. •Azure DevOps then uses WebDeploy (the same technology used by Visual Studio) to deploy the artifacts to your Azure WebApps.
Checkout this document for more details -https://github.com/projectkudu/kudu/wiki/VSTS-vs-Kudu-deployments#how-does-visual-studio-team-services-deployment-work
ajkuma 22,521 Reputation points Microsoft Employee

2020-03-03T11:23:36.98+00:00

Sorry to hear that you're still experiencing this issue. could you please share the name of the WebApp directly here or indirectly for further investigation?

As mentioned above, kindly checkout the thread https://github.com/Azure/app-service-announcements-discussions/issues/129 for .NET Core 3.1 Availability on App Service for the latest update.

If the issue still persist, I wish to engage with you offline further to understand some more details about the problem, have a closer look and provide a specialized assistance, please send an email to AzCommunity[at]Microsoft[dot]com referencing this thread and the Azure subscription ID, I will follow-up with you.
ajkuma 22,521 Reputation points Microsoft Employee

2020-03-03T11:25:49.697+00:00

Could you please share the name of the WebApp directly here or indirectly for further investigation?

As mentioned above, I wish to engage with you offline further to understand some more details about the problem, have a closer look and provide a specialized assistance, please send an email to AzCommunity[at]Microsoft[dot]com referencing this thread and the Azure subscription ID, I will follow-up with you.
Michael Ray 1 Reputation point

2020-04-09T02:54:41.79+00:00

So now it's april, and I still can't choose windows when provisioning an app service with .net core 3.1. What's going on with this?

1 answer

JeffM-MSFT 6 Reputation points Microsoft Employee

2020-04-22T23:38:11.5+00:00

You may have found a solution for your application already from your offline conversation but I'd like to inform that .NET Core 3.1 is now Generally Available on App Service and should solve the issues you described above including the Kudu build and the ability to choose Linux or Windows in the portal without it being grayed out. Announcing-.NET-Core-3.1-LTS-Generally-Available-on-App-Service.html
Please sign in to rate this answer.

0 comments No comments
Sign in to comment