Oh, the most annoying thing ever :( So I spent some time trying to get my old application to compile using c# 7 and managed it, now that is finally working I was ready to setup devops.
I created my pipeline as usual, but the first issue was when I pushed a build, it moaned about not supporting .net 4.7.2. Awesome.
So I downgraded the project to 4.6.2 and then ran my pipeline again and now I get this:
Invalid token '=>' in class, struct, or interface member declaration
I have checked the nuget restore in devops and it is using .net compilers 2.10.0.
I am at a loss. Does anyone know how I can fix this?
Your Agent pool may need to be Hosted VS2017.
As #NicoD mentioned, we also are building c# 7 projects with no issues by targeting this host.
For other users who have custom/hosted agents, you have to install this in server where agent runs:
Be sure you have correct Build Tools for Visual Studio installed: How can I install the VS2017 version of msbuild on a build server without installing the IDE?
And don't forget install this option too: MS-Build 2017 "Microsoft.WebApplication.targets " is missing
Related
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'
When I try to run (debug) functions in Visual Studio 2017 on one of our machines, the following dialog pops up!
The target framework for the project is <TargetFramework>net461</TargetFramework>. For some reasons I am not able to install .NET 4.7.1 and now I am completely lost. I am sure it was functioning in the past on the same machine. Probably one of the updates caused it.
Any idea how to resolve it?
This is because the latest version of the Azure Functions Tools for Visual Studio now requires .NET Framework 4.7.1 (as of February 2018).
Note that this does not impact the target framework that you compile against - only the target framework your code runs against. Similarly, when you run in Azure, you can expect the .NET runtime version to be .NET Framework 4.7.1 (at the time of writing).
I tried implementing the solution mentioned in comment. However, it didn't work for me. However, reverting the Azure Functions Tools to previous version worked. Thanks Chris for pointing that it was Azure Tools and not any packages that caused it.
If anyone else should come across this.
For me, the issue was the actual func.exe config that needed to be upgraded.
Navigate to:
C:\Users[USER]\AppData\Local\AzureFunctionsTools\Releases[VERSION]\cli
.. my version was 1.4.0
Modify the func.exe.config to match the .net version installed
.. it was 4.7.1
We use TeamCity as our CI server (but I imagine this applies to any build server).
We have not installed the azure SDK on the build server and are able to build the projects which use the SDK using the workaround described here.
I now want the server to produce the packages for deployment to Azure, but when I run an MSBuild task to create the packages (as directed here) I get a strange error
error MSB4057: The target "WatGetTargetFrameworkDirectories" does not exist in the project.
which yields few useful google results.
Do I need to install the SDK? Or is this error related to something else?
WatGetTargetFrameworkDirectories is a target from AzureSDKs .targets file. Looks like your error related to Azure SDK.
Except it could be more subtle error related to not very good msbuild Azure Targets. For our own azure packaging we did need to call 2 targets "Clean;CorePublish", not just "Publish". Maybe this will also help you.
Side note: why you don't want to install AzureSDK on TeamCity BuildAgent? Build agents made exactly for that - to have frameworks you need for build. Also 1.6 and 1.7 AzureSDKs can be installed side-by-side.
I was just upgrading my project from sdk 1.3 to 1.7 and I noticed that now when I build the application the package(cspkg) is not created with the build. I have go click on publish to create a package. Is there a way to tell VS to create a package everytime a build is triggered.
Also using msbuild is there a way to do the same thing. I have multiple projects under a solution, Most of which are just libraries and then there is this azure app. Is there a way to specify a single msbuild statement with params to tell the azure app to create the package as well as build the other projects. Also when I specify debug the debug package should be created and when I specify release switch the release package should be created.
How could I do the same thing on my build server as well where I have a .proj file which specifies the sln to build. How could I mention a switch to build the package there.
Thanks,
Kunal
You can configure CSPACK command (Be sure to have CSPACK.exe launched from SDK 1.7 Path otherwise you will get some schema related errors with SDK 1.6 project) as Post Build event in your Windows Azure Application Build settings. This way when you will build, after successful build CSPACK command will run and package your application. Same way you can configure your MSBuild configuration. I just tested and it worked for me.
Visit this MSDN article on packaging a cloud service to learn more.
You can do this using msbuild as well. See the Resolution section of this question.