We have a Azure Function which is built in .Net Framework 4.6 and recently we have updated the Azure Functions with .Net Framework 4.8 which works good in locally. So we tried to publish this to Live by going to select the existing Azure Function as below image.
But we are unable to publish due to below error (Publish has encountered an error).
Can you please suggest me If I missed any settings/configuration.
As far as i know, azure function v1 support dotnet framework4.7 as the document shows:
I test it in my side with dotnet framework 4.8 and show the same error message as you, so i think you'd better change the dotnet framework from 4.8 to 4.7.
Related
I've been given the task to debug an Azure function on VS 2022 targeting .Net Framework 4.8. While its straight forward to debug it in .Net Core 3.0 or later, I keep getting the error - A project with an Output Type of Class Library cannot be started directly, when I try to run it by pressing F5. Looking around, I followed this link to download Azure functions core tools; https://github.com/Azure/azure-functions-core-tools but it hasn't worked even after restarting VS.The function has following properties:
While I can run and debug functions written in .Net Core 3.1 and .Net 6 but I'm struggling with this legacy function. Any help is really appreciated.
We have tried to create Azure function with .net framework 4.8 and successfully tested in our local by using visual studio 2022.
We have installed azure function core tool 4x on our local. Make sure that only one azure function core tool has installed on our local.
Created one azure function with http trigger by selecting .net framework and targeting it to version 4.8.
Able to debug successfully as shown below
For more information please refer this MICROSOFT DOCUMENTATION
I keep getting this error when I try to run the pipelines for my azure backend functions:
[error]C:\Users\VssAdministrator.nuget\packages\microsoft.net.sdk.functions\1.0.27\build\netstandard1.0\Microsoft.NET.Sdk.Functions.Build.targets(41,5): Error : It was not possible to find any compatible framework version
The framework 'Microsoft.NETCore.App', version '2.1.0' was not found.
It's a pretty old program, but yesterday was the first time that the build has failed and I don't know how to fix it. It happens both in the develop and main branch so I'm guessing it's a change from Azure.
As documented in this GitHub issue .NET Core 2.1 has been removed from all build agent images.
Possible impact
If your project depends on a pre-installed .Net 2.1 it can be broken.
You can try to use the setup dotnet task to explicitly install .NET Core 2.1.
- uses: actions/setup-dotnet#v1
with:
dotnet-version: '2.1.x'
Please be advised .NET Core 2.1 has been out of support since August 21, 2021 (see .NET and .NET Core Support Policy). An upgrade to a currently supported version like .NET Core 3.1 or higher should not be a lot of work and is well worth the effort.
How can I fix deployment problem? upgraded entity framework core from 3.1.4 to 3.1.5. Result mvc core web app runs in VS, but fails in Azure.
Dot Net core 3.1 with EF 3.1.4 in Azure ran OK.
I updated the Nuget EF packages to current stable 3.1.5, and the result runs locally, but fails when deployed to Azure with message:
"could not load file or assembly 'Microsoft.EntityFrameworkCore, Version=3.1.5.0"
I used the Azure AppService Console and can see the EF versions have the same date as my local files "5/1/2020".
The FileExplorer details screen shows the version as 3.1.5, while the error message says it can not load 3.1.5.0. I searched, but did not find any other people with this problem.
I think is missing the reference there. If you can, check in the folder "packages" if there is a EF 3.1.5 there. Also, check if there is some places which is showing just 3.1.5.0 and try to change to 3.1.5 as is showing in the nuget library.
Finally solved the problem. It involved information from this Microsoft article:
https://learn.microsoft.com/en-us/aspnet/core/test/troubleshoot-azure-iis?view=aspnetcore-3.1#clear-package-caches
Needed to uninstall some nuget packages, use command line nuget commands to clear nuget cache, and then re-install latest nuget packages. Redeployed to Azure and the site works again.
We build our web app with Azure DevOps pipelines and deploy into Azure with an Azure DevOps release. I think today netcore got updated to netcore 3.1.4 on our build agent. But now our Azure DevOps deployment fails, because the netcore 3.1.4 runtime is not yet installed on our app service in Azure.
The error message we are getting:
Could not find 'aspnetcorev2_inprocess.dll'. Exception message:
It was not possible to find any compatible framework version
The framework 'Microsoft.AspNetCore.App', version '3.1.4' was not found.
- The following frameworks were found:
2.2.8 at [D:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
3.0.3 at [D:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
3.1.1 at [D:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
3.1.3 at [D:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
You can resolve the problem by installing the specified framework and/or SDK.
This makes sense and can happen, but what is the best way to go about fixing this?
I could fix my build to a specific netcore version. But I don't like this, because we do want to keep updating to newer versions, but we don't want a version that is not available in Azure app service.
Am I correct in thinking that we would have to install our services self contained, because otherwise we could get into this issue more often when Azure DevOps is faster with installing patches than Azure?
Or is there a way to force update Azure app service to the new netcore 3.1.4 security patch which would be ideal I think?
I just need some guidance in what is the best approach to fix this issue?
Or is there a way to force update Azure app service to the new netcore 3.1.4 security patch which would be ideal I think?
AFAIK, there is no such a way to force update Azure app service to the new netcore 3.1.4.
We could keep track on the latest releases on the https://aspnetcoreon.azurewebsites.net/, but we could not update it at this moment.
To resolve this issue, we recommend that you publish your app as self-contained produces an application, which includes the .NET Core runtime and libraries, and your application and its dependencies. Users of the application can run it on a machine that doesn't have the .NET Core runtime installed.
Publishing your app as self-contained produces a platform-specific executable. The output publishing folder contains all components of the app, including the .NET Core libraries and target runtime. The app is isolated from other .NET Core apps and doesn't use a locally installed shared runtime. The user of your app isn't required to download and install .NET Core.
You could check this document .NET Core application publishing overview for some more details.
Hope this helps.
If you want version of netcore to be automatically updated as an updated version is available, building our service as self-container seems like a good option: no need to have anything installed on the machine running (ie the version on Azure DevOps and Azure Web App don't have to match).
The main downside of this approach is that the build is going to less deterministic: running your build twice with on the same commit might create different binaries depending on what is currently install on the build agent. if you want to know more, here is an interesting post arguing about why deterministic build is important.
To keep the build determinitic, you can use the Use .Net Core task at the beginning of the build (that will make sure that the desired version of the dotnet sdk is on the agent). You could also add a global.json in your repository to lock for both the build on your dev box and in Azure Dev Ops.
This is a common topic of discussion, and you can find a lot of blogs advocating one or another side.
There were big discussions started when Microsoft released LTS net core 3.1 and it took some time before Azure start supporting the 3.1 runtime as well.
You could find a lot of blogs strongly suggesting to deploy your web apps as self-contained (runtime is ~100MB in size) and cut loose the dependency towards Microsoft supporting the latest runtime. While others advocate that the applications should remain as light weight as possible and the runtime should be set in the pipeline. But that is still up on you. I, myself prefer to deploy self-contained apps after my bad experience with net-core 3.1.
There is no established best practice.
In the past , I've run into the same situation, you can fix this by manually setting the value from RunTime Stack drop down. If you manually update the build processes .yml file
RuntimeStack: 'DOTNETCORE|3.1'
I've uploaded an asp.net core app with VS 2019 publish, and targeted the app netcoreapp2.2.
The app worked perfectly, but when checking some performance issue, I've noticed that in Azure portal-Configuration-General settings, the app stack settings was .NET (not .net core), and version is V4.7.
This raises 2 questions:
1. How is it even working...?
2. Why VS deployment process wasn't configured with the settings displayed in publish section?
VS publish settings:
Azure settings:
Thanks!
I fixed the issue by updating the following lines in .sln
from:
Visual Studio Version 16
VisualStudioVersion = 16.0.29613.14
To:
# Visual Studio Version 16
VisualStudioVersion = 16.0.30011.22
ASP.NET Core 2.x can target .NET Core or .NET Framework. ASP.NET Core apps targeting .NET Framework aren't cross-platform—they run on Windows only. Generally, ASP.NET Core 2.x is made up of .NET Standard libraries. Libraries written with .NET Standard 2.0 run on any .NET platform that implements .NET Standard 2.0.
When you published to the .NET Core 2.2 runtime app you would always get the following warning message:
"There was a problem starting MyProjectName on MyWebAppServiceName. Your application requires the .NET Core 2.2.0 runtime, but Microsoft Azure App Service only support the following versions:.
One way to fix this problem is by changing the deployment mode to self-contained in the publish settings, which will allow the application to carry its own runtime."
Refer to this similar case.
Edit:
When you create webapp on portal, you could go to arm template to get the stack setting which is set as CurrentStack: dotnetCore. But when you publish project on VS, it could net set the runtime.
So, it may a VS issue that you could give feedback or you could create webapp on Azure first which set runtime as .Net Core and publish project to it using VS.