danieljackson avatar image
0 Votes"
danieljackson asked azure-cxp-api edited

Web App Service for Net Core 3.1 is Faulted

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,!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?

· 25
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

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 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.

1 Vote 1 ·

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.

0 Votes 0 ·

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.

0 Votes 0 ·
Show more comments

Can't even post a comment.

0 Votes 0 ·

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.

0 Votes 0 ·

(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'.

0 Votes 0 ·

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 :

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.

0 Votes 0 ·

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?

0 Votes 0 ·

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}, you will see your sources under site\repository, as well as various deployment related artifacts.

0 Votes 0 ·
Show more comments

1 Answer

jefmarti avatar image
0 Votes"
jefmarti answered

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

5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.