I can't choose runtime-stack version when I try to set up GitHub as source in Azure Distribution center:
Version 3.1 is the only available option. My app references ASP.NET Core 6 and targets .NET 6 so when I run the Workflow in GitHub to test the build fails. I can easily change from
dotnet-version: '3.1.301'
to
dotnet-version: '6.0.x'
in the created workflow file created by Azure.
My question is why can't I choose version in Azure portal?
AFAIK you cannot change Version over there. Alternatively, If you want to change the Runtime Stack version, you can change by following below workaround:
Firstly open your app
Then click on Configuration in Settings
Then on General Setting
Then on .Net Version to change to required version
Related
I'm learning Azure functions, and after setting up an initial project the tutorial suggests to select Project > Add new Item > Azure function.
On my end, I don't see Add New Item in the menu, but if I right click on the .csproj file I see add new item, however, I don't see an option for adding an azure function.
Expected behavior (screenshot from tutorial)
Actual behavior on my end:
I checked this post where it says to add "Azure Functions and web job tools" though I don't see that as an option on my side.
Also referenced this post:
Missing Azure functions template under Add new item in Visual Studio
It recommended making sure I have the Azure SDK workload (which I do) and installing this SDK: Microsoft.Net.Sdk.Functions
I went to my folder and ran this command so as far as I know it's installed at this point.
dotnet add package Microsoft.NET.Sdk.Functions --version 4.1.3
This is my current file structure and .csproj file.
When setting up VS, I selected Azure SDK as a workload. Also, if I go to File > New > Project, I have an option for Azure functions.
Any insight as to why it's not showing up for me would be appreciated. If you need me to clarify anything, please let me know.
As you have followed one of my practical workarounds #7004818, make sure you have done the below configuration:
Download & Install the Azure Functions Core Tools, VS 2022 Current Version 17.4.4
In Visual Studio installer, Select the below options:
- Web & Cloud: ASP .NET & Web development, Azure Development
- Desktop & Mobile: .NET Desktop development
- Other toolsets: Visual Studio Extension Development
You are developing the Azure Functions in .NET So, install the respective Version SDK & Runtime.
On the Same above Post, the user #GraceA added a point to my answer which is to check the NuGet Package Source Install/Update is missing and there are steps given in the answer for updating/installing it.
[VS NuGet Package Update Gif Image1]
[VS Azure Functions Toolset Update Gif Image 2]
The Same issue registered on MS Q&A Forum #386611 where the user has resolved it by updating the NuGet Package Source.
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.
I'm migrating from VS2015 to VS2017, and updating a repo's solutions to be able to be compatible with VS2017. In the process, I'm also updating the Azure SDK version from 2.7 to 3.0.
I'm setting up a fresh dev environment, and installed Azure SDK 3.0 via VS2017's Azure development workload.
When I opened the solution file in the repo, I got one notice per cloud service project that its Microsoft Azure Tools version was getting upgraded from 2.7 to 2.9...
...and the ProductVersion tag in the corresponding .csproj files was updated from 2.7 to 2.9.
Questions:
Why wasn't this updated to 3.0?
Is there anyway for me to update it
to 3.0 without manually editing the csproj file? I don't see an
option to do so in Properties when I right click the cloud service
projects in Solution Explorer.
Is there some reason I shouldn't be
doing this?
"Microsoft Azure Tools - v2.9" mentioned in your screenshot is just a little misleading.
Underlying reason is that Microsoft hasn't really changed the version number of most components as part of 3.0 SDK release. Even the binaries get installed in the same folder as 2.9.
Good news is that you don't need to do anything special apart from converting the project to target latest version, which you're already getting prompted for.
So once you do convert your project as per the prompt, you're essentially working with SDK 3.0, even though version string says v2.9, because as the links explain, most of the components haven't changed major version number as part of SDK 3.0 version (when comparing with 2.9)
Here are some of the links which talk about this -
Azure SDK for .NET 3.0 Release Summary
No breaking changes to the Azure SDK 3.0 have been introduced in this
release. There is also no upgrade process needed to leverage this SDK
with existing Cloud Service projects. To allow use of the Azure SDK
3.0 without requiring an upgrade process, Azure SDK 3.0 installs to the same directories as Azure SDK 2.9. Most the components did not
change the major version from 2.9 but instead just updated the build
number.
Visual Studio 2017 latest installer does not install Azure SDK 3.0
In this link look at the response from Devin Breshears - MSFT
Azure 3.0 SDK Install Weirdness
An independent blog talking about the same issue.
I am deploying Orchard to Azure cloud services (webrole) without any code changes to the official stable release. However, when I navigate to that freshly deployed Orchard cloud service (webrole), I see a YSOD with Could not load file or assembly 'Microsoft.WindowsAzure.ServiceRuntime, Version=1.7.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.
As a work around, if I enable Local Copy=True (i.e. modify source), then this specific YSOD goes but is replaced by another one for msshrtmi). But more importantly, I'm able to deploy the pre-built downloaded Orchard Azure (1.7, prebuilt off same GIT src tag), without issues, so I'd rather fix the root issue than go down a rabbit hole of workarounds and drift further from the official sources.
How I'm running into this issue:
Download source from GIT (http://orchard.codeplex.com/SourceControl/latest, I used commit 5e0c26f73cf5, )
Run ClickToBuildAzurePackage.cmd script
Edit buildazure\Stage\ServiceConfiguration.cscfg to put in connection string's to point to the real Azure storage account (vs Local Storage).
Deploy both the files in buildazure\Stage to Azure via the windowsazure.com portal
Navigate to site (eg: http://OrchardTest.cloudapp.net)
Enjoy the yellow-screen-of-death :(
Our local build system:
Windows 8, x64
VS2012.3
Azure SDK 1.7, 1.8, 2.0
Question:
Has anyone deployed to Azure successfully? Any ideas how to resolve this issue?
There should never be a need to CopyLocal True on the Azure Service Runtime. That is automatically included in the package, defined by your Cloud Services project (In this case, Orchard.Azure.CloudService). And actually, I could imagine that CopyLocal True might cause issues if the bin contains a different version of the Service Runtime than the Azure package was built under.
Orchard Azure uses the Azure 2.0 libraries. It shows that you have the 2.0 SDK installed because you can compile the Orchard.Azure.CloudService project to make a package. Cloud Service projects have different a project guid for each version of the Azure tools, so without the v2.0 SDK, it would be an unknown project type. However, with your Orchard website picking up ServiceRuntime v1.7, it seems that something is amiss with your local environment, as it should still identify with v2.0.
When you open Orchard.Azure.sln, check the Properties on the Microsoft.WindowsAzure.ServiceRuntime reference within the Orchard.Azure.Web project. What is the version that Visual Studio lists on that reference? It should be 2.0.0. If it does not, my best recommendation would be to reinstall the 2.0 Libraries.
The deployment steps as you have defined work just fine with no YSOD. I successfully tried it just before writing this; it did not reproduce your issue.