Closed fabiocav closed 4 years ago
Great, looking forward to it... And is this announcement also valid for App Service on Linux ?
@ardacetinkaya ; yes, this applies to App Service on Linux as well. That should actually be globally deployed by now.
I still don't see 3.1 available.
.
Trying to run app on .net core 3.1 always get this
windows 2019, Even if added this task: And also tried this config:
@botezatpv you should use SDKs version like 3.1.100 as version not 3.1.0
Then, it would be work, at least mine is solved like this.
You may check https://github.com/dotnet/core/blob/master/release-notes/releases-index.json for available ones in Azure DevOps.
@ardacetinkaya I've used all possible combination of options :) None worked. Just tried once again to switch to sdk and still doesn't work at all. For 3.0 worked fine
3.1 is currently in the following regions:
Will continue to post updates as it moves forward
@fabiocav When approximately update will come to EU servers?
@botezatpv we expect to be fully deployed by Monday (December 9th).
Additional stamps have just received the update and we're at about 20% global coverage.
@fabiocav ok, thank you for info!
@fabiocav slightly off topic here, but will app services continue to support .Net Core version 2.2 as I know Microsoft support ends this month?
@botezatpv we expect to be fully deployed by Monday (December 6th).
Additional stamps have just received the update and we're at about 20% global coverage.
@fabiocav Isn't Monday the 9th?
Also @davidhendrickmb Don't think there is any policy on removing .net core versions from app service as it still has 1.0 and 1.1 available. You should be fine to stick on 2.2 but without any update/security patches
@fabiocav Isn't Monday the 9th?
Yes :). Sorry about the typo... will correct the date above to avoid confusion.
About the support for 2.2, the comment above is correct. The runtime won’t be removed (the 2.2.8 update is actually going with the same deployment), but the end of life policies defined by the .NET team still apply.
Runtime deployment is now finished. 3.1 is now available in all App Service regions.
Great stuff guys.
Now for that SDK.... ☺️
I don't see 3.1 runtime available(both windows, linux), can you guys confirm ?
Adding @btardif here - this area of the portal is updated once the core runtime has been rolled out. From the looks of the map, it has been. Byron, any ETA on when this will update?
We are in the process of rolling out the update to light up .NET Core 3.1 in the UX for Linux workloads. This is expected to complete world wide sometime this week.
Update to enable Windows scenarios should follow once back-end deployment completes worldwide. Tentative ETA for that is 12/20
How can I know if my deployment requires SDK? For example, I am using ZIP deployment. I saw that it uses kudu service, so it probably requires SDK. But is there any info about which deployment methods require SDK and which don't?
@fabiocav Isn't Monday the 9th?
Yes :). Sorry about the typo... will correct the date above to avoid confusion.
About the support for 2.2, the comment above is correct. The runtime won’t be removed (the 2.2.8 update is actually going with the same deployment), but the end of life policies defined by the .NET team still apply.
Thank you very much!
How can I know if my deployment requires SDK? For example, I am using ZIP deployment. I saw that it uses kudu service, so it probably requires SDK. But is there any info about which deployment methods require SDK and which don't?
Ideally you shouldn't have to differentiate between needing SDK or not , that's the reason why we don't make this selection public until we have full support.
CC: @JasonFreeberg since this is deployment related. I don't think we have any documentation covering this question.
Is it correct that a .NET Core 2.2 app would automatically begin using the 2.2.8 runtime with this rollout without any intervention? If so, I believe it has caused a breaking change related to https://github.com/aspnet/AspNetCore/issues/14996
Is it possible to pin a specific minor .NET Core runtime version (eg, 2.2.7)?
UX rollout is now complete to enable 3.1 on Linux hosted App Service:
Windows hosted App Service option will be enabled once world wide rollout of 3.1 SDK to App Service backend is complete.
So our website is running fine on Azure App Service on 3.1, but our App Service which uses a dll which is built with the new C++/CLI dotnet core stuff gives the following error:
Could not load file or assembly 'DLLName, Version=1.0.7277.24961, Culture=neutral, PublicKeyToken=null'. An attempt was made to load a program with an incorrect format.
Tried both 32 and 64 bit versions (both are working fine locally), anything we're missing, is this a bug on Azure or is this because some part still needs to be rolled out?
What is current ETA for 3.1 SDK rollout?
@fabiocav, you mentioned that 3.1 LTS is available in all regions, but I just tried to deploy it in Australia Southeast
and could not select Windows as the platform (and Linux deployment failed). Can you advise when 3.1 LTS will be supported on linux? I also tried other regions, but Windows
is greyed out:
So our website is running fine on Azure App Service on 3.1, but our App Service which uses a dll which is built with the new C++/CLI dotnet core stuff gives the following error:
Could not load file or assembly 'DLLName, Version=1.0.7277.24961, Culture=neutral, PublicKeyToken=null'. An attempt was made to load a program with an incorrect format.
Tried both 32 and 64 bit versions (both are working fine locally), anything we're missing, is this a bug on Azure or is this because some part still needs to be rolled out?
@jgoyvaerts Did you end up resolving this? We've been experiencing a similar error where the DLL in question is Microsoft.Extensions.Primitives.
3.1 LTS appears to be supported on Linux only and even a "code" deployment is still executed from a container. Is this correct?
December 13th has come and gone, December 20th has come and gone but .Net Core 3.1 LTS still doesn't seem to be supported on Windows in Azure App Service:
When is this going to happen? I've just migrated my app to .NET Core 3.1 and I was hoping to do an in-place upgrade of the stack but this is essentially blocking me.
It's probably just a UI issue. The 3.1 runtime has been fully deployed. Do you have an app service already created? If not try create one with the Windows option and net core 3.0. Then go into that app service and on the menu on the left hand side go to Console. Type in "dotnet --info". If you can see that the 3.1 runtime is there then it doesn't matter what the UI says. As a point of interest I just checked the Configuration page on my app service and the Stack setting was still sitting on Full .Net Framework v4.7. In fact it looks like once you have an app service created there is no option for the version of .net core
Ok. Good point. I did try that and it does seem that the 3.1 runtime is installed even though the UI would have you believe otherwise. But now that I have deployed my app to it, I am getting a 503 Service Unavailable. Seems like the dotnet process is not running, I have the same app running in another test environment running on Linux and there, I can see the dotnet process is alive and running.
I have tried changing the Framework from v4.7 to .NET Core (as you pointed out, it doesn't let you pick the version of .NET Core), but no joy! Any ideas?
That error almost sounds like a startup issue. Unfortunately those sort of issues tend to occur before it can get to application insights. For cases like that I normally try manually starting the app from the Console and seeing if you get any error messages. I think the 3.0 and 3.1 you just need to do "appname.exe" (with the correct name obviously). Earlier veersions of net core would need "dotnet appname.dll"
Tried that, got this:
Interestingly enough, I can replicate the behaviour locally too, I think, invoking the exe from CLI just seems to freeze, no output, no error nothing. Something's not quite right! Not sure quite what though. I will dig deeper but in the meantime if you've any ideas, I am all ears! Thanks.
Ok! Found the issue! By default App Services seem to have the ASP.NET Core x64 runtime extension installed, but if your app is a 32 bit app (like mine is) you also need to install x86 runtime extension:
This docs article triggered the thought that ultimately helped solve the problem!
Once you do this, it works! 👍 Thanks for the assist!
Oh that's interesting. Just checked mine. No extensions are installed and mine is 32 bit
Could have been that in my case, the default was somehow x64 and I didn't realise, not sure. I would have also expected it to just work out of the box. Apparently not so! It would be good to have someone from MS comment on this (but hey, its Xmas so may be not) :) Have a merry one!
Tried that, got this:
Interestingly enough, I can replicate the behaviour locally too, I think, invoking the exe from CLI just seems to freeze, no output, no error nothing. Something's not quite right! Not sure quite what though. I will dig deeper but in the meantime if you've any ideas, I am all ears! Thanks.
Actually just releaised that it hasn't frozen. It just isn't outputting any logging. Add Console logging from https://docs.microsoft.com/en-us/aspnet/core/fundamentals/logging/?view=aspnetcore-3.1
.NET Core 3.1 not working in a FREE app service plan in the West Europe
region.
I am trying the tutorial at https://docs.microsoft.com/en-us/azure/app-service/containers/quickstart-dotnetcore with the following modifications...
az webapp create
with the --runtime "DOTNETCORE|LTS"
option instead of DOTNETCORE|2.2
but when I try deploying via local git push I get the error
Error: Platform 'dotnet' version 'lts' is unsupported. Supported versions: 1.0.16, 1.1.14, 2.0.9, 2.1.13, 2.2.7, 3.0.0
Azure UI allows me to select dotnet core 3.1 as the runtime, but I can only deploy successfully if I select 3.0.0 in the UI and target netcoreapp3.0
in my .csproj
Am I doing something wrong ?
Yeah I did figure it out later that that's what was happening locally , however on App Service it threw that time out error and I was still getting 503. Like I said, it had to have been the bitness issue because as soon as I flipped that, it worked!
@explorer14 How are you publishing your app? What are your publish settings? IS it set to x64 or x86?
@jpeg729 I'm not too sure of the cli part, however on the Azure UI it should work. Have you tried to update to target netcoreapp3.1 once you have a working 3.0 version. Also similar to above what is your publish method and settings?
@ChrisJollyAU I am new to all this, so I followed the tutorial almost to the letter. I had to downgrade everything to 3.0 to get it to work, and then I tried targeting netcoreapp3.1 in the csproj and choosing .NET 3.1 in the UI. But as I said, it refuses to build if either or both versions are set to 3.1.
By refuses to build do you mean locally on your pc? What's the error? Also in Auzre UI can you go to the web app, go to Console and type "dotnet --info" . What's the output?
It builds absolutely fine on my pc no matter the target version. I started over to see if it works any better. I created the web app using the command line
az webapp create --resource-group helloResourceGroup --plan helloAppServicePlan --name helloDotNet --runtime "DOTNETCORE|LTS" --deployment-local-git
Then in the Azure portal I found the webapp and selected SSH. Here is the result
In the configuration no stack is selected as you can see here
So I choose dotnetcore version 3.1
And after reloading the SSH tab in the browser we get this.
And yet when I git push azure master
I get this...
user@ubuntu:~/code/azure/hellodotnetcore$ git push azure master
Password for 'https://details.removed....scm.azurewebsites.net:443':
Counting objects: 49, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (41/41), done.
Writing objects: 100% (49/49), 73.95 KiB | 3.89 MiB/s, done.
Total 49 (delta 11), reused 0 (delta 0)
remote: Deploy Async
remote: Updating branch 'master'.
remote: Updating submodules.
remote: Preparing deployment for commit id 'ab3370dea9'.
remote: Repository path is /home/site/repository
remote: Running oryx build...
remote: Build orchestrated by Microsoft Oryx, https://github.com/Microsoft/Oryx
remote: You can report issues at https://github.com/Microsoft/Oryx/issues
remote:
remote: Oryx Version : 0.2.20191105.2, Commit: 67e159d71419415435cb5d10c05a0f0758ee8809, ReleaseTagName: 20191105.2
remote: Build Operation ID: |rYE4zNR5iSM=.b443ae30_
remote: Repository Commit : ab3370dea96dcb65a95eb63c2bb471511def2b45
remote:
remote: Error: Platform 'dotnet' version '3.1' is unsupported. Supported versions: 1.0.16, 1.1.14, 2.0.9, 2.1.13, 2.2.7, 3.0.0
remote: Deployment Logs : 'https://hellodotnet.scm.azurewebsites.net/newui/jsonviewer?view_url=/api/deployments/ab3370dea96dcb65a95eb63c2bb471511def2b45/log'
To https://hellodotnet.scm.azurewebsites.net:443/helloDotNet.git
* [new branch] master -> master
user@ubuntu:~/code/azure/hellodotnetcore$
My questions
@jpeg729 Can you try using "DOTNETCORE|3.1" instead of "DOTNETCORE|LTS" and see if that works? App Service on Linux definitely supports 3.1 because I just had an app running on it 2 days ago. Although, I deployed the infrastructure using ARM template and then deployed my app into it via Azure DevOps. In the ARM template though, I remember using "DOTNETCORE|3.1".
I just ran the following command
user@ubuntu:~/code/azure/hellodotnetcore$ az webapp config show --resource-group helloResourceGroup --name helloDotNet --query linuxFxVersion
and got the response
"DOTNETCORE|3.1"
I've had a bit of a look and I haven't seen anywhere that mentions using DOTNETCORE|LTS . Best I've seen is that the default is DOTNETCORE|2.2 . Have you tried using something like DOTNETCORE|3.1 ? Anyway now that you have set it in the UI to 3.1 and from the output that looks fine there for the runtime.
There is a difference between the runtime and the SDK. By the looks of it, it is trying to build and not finding the correct SDK
I do have a suggestion. On your pc do a "dotnet publish" and take the folder it creates and upload it to your web app (via ftp or any other way you are comfortable with)
DOTNETCORE|LTS
is listed in the output of the command az webapp list-runtimes --linux
but DOTNETCORE|3.1
isn't
Starting over
The command user@ubuntu:~/code/azure/hellodotnetcore$ az webapp create --resource-group helloResourceGroup --plan helloAppServicePlan --name helloDotNet --runtime "DOTNETCORE|3.1" --deployment-local-git
gives the following message
Linux Runtime 'DOTNETCORE|3.1' is not supported.Please invoke 'list-runtimes' to cross check
I'll try creating it with 3.0, then upgrading it in the UI and copying the output of dotnet publish. I'll post the results this evening.
@ChrisJollyAU as for the bitness issue, I just checked and the Platform Target is set to AnyCPU
so I am not explicitly targetting one or the other. I am using Cake script to publish the artifacts and having double checked it, I can say I am not targetting a specific platform there either. So the app should be able to work with either (unless some dependency dlls in my app are specifically built for x86)
Its also being deployed as a Framework Dependent Deployment app which according to the docs here, will require an extensionfor appropriate bitness depending on whether its a current release or a preview release (3.1 is neither but the docs don't cater for that).
The configuration of the app service is for some reason fixed at 32-bit and it doesn't allow me to change it:
I am highly suspicious of this. May be that's why I've had to install the 32bit extension as well. Not sure!
It works if I deploy the publish folder contents via ftp. I have finally understood what they meant when they said that .NET 3.1 was available on App Service but we would have to wait for the SDK. It means it can run .NET 3.1 apps, but it can't build them, so we can deploy successfully only if the build is done by our machines.
Discussion for .NET Core 3.1 Availability on App Service.