I am trying to deploy a .NET 6 WebJob to an existing Azure App Service using Azure DevOps. I updated the App Service from ASP.NET V4.8 to the .NET 6 (LTS) version.
I installed the ASP.NET Core 6.0 (x64) Runtime extension
I also verified the .net version in the Azure CLI console:
Using the Azure App service deploy task in Azure DevOps, I get the following error message
The application pool that you are trying to use has the 'managedRuntimeVersion' property set to 'v4.0'. This application requires 'v6.0'. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_APPPOOL_VERSION_MISMATCH. Learn more at: https://go.microsoft.com/fwlink/?LinkId=221672#ERROR_APPPOOL_VERSION_MISMATCH.
Can anyone help me understand what I need to do to update the managedRuntimeVersion? My applicationhost.config file does have v4.0, but I don't have the rights, nor does it seem like the correct fix to modify this directly. Any ideas how I can update the managedRuntimeVersion, or what else I'm missing here?
Related
Today I deployed a new Azure Function App targeting .NET 7 Isolated as framework on Azure. To create the resource on Azure I used the wizard present on Visual Studio 2022, so I both created the new resource and deployed it using VS2022.
Going to view the Function App on Azure, I realized that the wizard created it by running it over the .NET 6 stack although it also offers me the Isolated .NET7 stack:
I was wondering if there was a specific technical reason and possibly if it is safe to switch to .NET6 from the .NET7 Isolated stack.
I have reproduced in my environment, and I have observed the same in my environment as below:
In my local Environment its .net 7 :
When I publish it to Azure its Changed to .net 6:
You can change there to .net 7 if any functionality doesn't work in . net 6 in portal:
I have also tried to create a .net 7 function app while creating portal:
I have observed that after creating its showing .net7
and when i deploy to this function app after deploying its showing .net6.
So, after deploying its changing to .net6. I would suggest if any functionality does not work, you can change to .net 7 manually.
See update 1 below:
This is a Windows WebApp on Azure AppService on a premium app service plan (it is a webapi written on netcore 3.1 C# project)
After setting up a new webapp with netcore 3.1 using az webapp create --runtime DOTNETCORE|3.1 (other params...) and webdeploy the app, at this point the app works.
When I look at the portal appService Configuration / General / Runtime, the runtime is blank If I set the runtime to .net / netcore 3.1 LTS through the UI, the app breaks (cannot start the W3 worker, events 2294 2276 are raised on startup).
Having spent a few hours thinking it was our app, I changed the runtime to net 5.0 and it started working.
Under the hood, the netFrameworkVersion property is being set like this:
on deployment when we have set runtime to netcore 3.1: 4.0
When selecting 3.1 LTS through the UI: 3.0
When setting 5.0 Early Access through the UI : 5.0
there is no property that seems to carry the DOTNETCORE|3.1 runtime value.
So to fix it rather than deleting and recreating the app service, I am trying to reset the runtime in CLI.
I can't find an az webapp CLI command to set the runtime like you can on az webapp create. The only option I can find for update is az webapp config is to set the --net-frameworkversion to 4.0 which sets the runtime in the UI to ASPNET 4.5 which is not the same as when you use --runtime DOTNETCORE|3.1 in the az webapp create command.
Looking for 2 things:
confirmation something is messed up in the Azure portal with the runtime setting.
a work around to reset the runtime to netcore 3.1 LTS outside of the portal (az CLI, az powershell?)
Update 1:
I tried deploying an new premium app service plan in North Europe, a new app service, Netcore 3.1 on Windows. No App Insights, networking, etc. Deployed the Visual Studio starter webapi app (weather forecast). Run it - it works. Change the runtime from blank to net/netcore3.1 in the portal, fails as above. Not one line of my own config or code in this scenario.
Feels to me like the portal may be messing up the app service config.
Also tried publishing from VS again with self contained 3.1 and it is no different.
OK, this was a bug in Azure. Now the portal Configuration/GeneralSettings lists netcore 3.1 as was set by the CLI create command.
The label changed too (3.1/2.1 used to be seperate entries).
I could not find any acknowledgement from MSFT.
I've deployed my code to an app service using Azure Devops CI release agent. Once I browse to the App service, it shows this error, stating that .net 5 isn't installed, and lists what is.
'The specified version of Microsoft.NetCore.App or Microsoft.AspNetCore.App was not found.'
This is what I have selected in the app service configuration, as it looks to be the only .Net 5 option.
Based on my test, the Azure App Service could support the .Net 5.
From the error message, it is indeed show that .net 5 hasn't been installed in the app service.
I could reproduce this issue too.
But when I select the .Net5 (Early Access) in Configuration and Save it, it will update the web app settings. Then the website could run successfully.
From your screenshot, you already selected this option. You could try to restart the App service and check if it could work.
On the other hand, you could try to create a new App Service with .Net5 (Early Access). Then you could directly use the App service with .Net 5.
Here is a ticket with the detailed introduction, you could refer to it.
I am trying to deploy a simple "Hello World!" .NET Core MVC 3.1 web application to an Azure App Service using the Azure Portal Deployment Center.
I created a my application using .Net Core version 3.1. (Visual Studio 2019 only has version 3.1 in the drop down, not 3.0.)
Visual Studio 2019 create wizard dropdown:
However this is not yet supported in the Deployment Center. You can select a runtime stack 3.1 (LTS) when adding creating the App Service Plan, but when you try and create a CI/CD pipeline with the Deployment Centre, it gives an error: "source.buildConfiguration.version: Property 'source.buildConfiguration.version' has invalid/unsupported value 'LTS'"
If I downgrade my web application to a version 3.0, and create the App Service/deployment pipeline with 3.0 using the Azure Portal Deployment Centre (building from my Azure Repo), it says the deployment has been successful, but it still shows the default site, not my "Hello World!" site.
Azure Devops Services indicates that the deployment has been successful:
Therefore, I expect to see my "Hello World!" site:
However, it still shows default site:
Given that there are no error messages, I'm not sure how best to debug what has gone wrong with the deployment. Any advice would be appreciated.
I ran into the same issue today... The solution was to change the
Startup Command (dotnet "myApp.dll" instead of dotnet run "myApp.dll")
under Configuration - General Settings in the App Service.
You might also check the Log Stream in your App Service for additional errors.
I also had to adjust the CD pipline task "Deploy Azure App Service" in Azure Devops to the Same Startup command.
Change .NET version to v4.8. Azure by default set it to v3.5, even though I selected 4.8 in the AppService wizard. My website uses v4.6.1.
And also, you have to change the document order in the configuration settings - default documents, in order to work and show the project enter image description here
I have a cloud service in azure with two .NET worker roles and i want to add a Node JS webrole.
I have installed the Node.JS tools for visual studio which creates templates from which should allow node apps to be deployed as a web role.
Packaging of the service goes smoothly, but after publishing the cloud service via visual studio the following error message is shown:
The file provided is not a valid service package. Detailed error code: presentation Invalid application runtime - a runtime component is missing:/base/x64/WaIISHost.exe.
But when I look in the package file for the cloud service using an archiving tool and go to /base/x64/, the exe "WaIISHost.exe" is there.
I am quite stuck at the moment. There seem to be few other people that have this issue and I have already reinstalled the Azure SDK as suggested here and I am using the latest version (2.9.1).