I have my Azure Web App configured to deploy from a local git repository - I just push my changes to the Web App git repo and it builds and deploys the site.
I just updated to my ASP .NET Core site to: "version": "1.0.0-preview2-003133", previously it was 003131 which worked no problems.
I now get the response when doing the git push:
remote: GETSDKTOOLINGINFO : error : The project is configured to use .NET Core SDK version 1.0.0-preview2-003133 which is not installed or cannot be found under the path D:\Program Files (x86)\dotnet. These components are required to build and run this project. Download the version of .NET Core SDK specified in global.json or update the SDK version in global.json to the version that is installed.
I would prefer to update the .NET Core version on my Web App than downgrade, but how?
In case you are wonder how I have 3133 already: https://github.com/aspnet/Tooling/issues/801
You basically can not update the dotnet version on Azure. Currently the version of dotnet that is running is 003131. So you still have to use the previous version.
How are you building your release package?
I had this yesterday using a VSTS build process, when using the 'Visual Studio' build task it will fail with this error currently - changing your process to use the "CMD line" build task and "dotnet publish" allows the build to complete successfully.
Related
Basically, I have a .netcore 3.1 proj (an exe) that runs flawlessly locally, both with and without a reference to another class library proj (.net framework 4.7.2). However, when I try to get the .netcore3.1 proj to build in Azure it only works when there is no reference to the class library. If there is a reference to the .net framework 4.7.2 class library, the build fails.
Below is the error within the publish portion of the pipeline. This is what comes up when the related code and reference to the class library are being used.
##[debug]Exit code 1 received from tool 'C:\hostedtoolcache\windows\dotnet\dotnet.exe'
##[debug]STDIO streams have closed for tool 'C:\hostedtoolcache\windows\dotnet\dotnet.exe'
##[error]Error: The process 'C:\hostedtoolcache\windows\dotnet\dotnet.exe' failed with exit code 1
##[debug]Processed: ##vso[task.issue type=error;]Error: The process 'C:\hostedtoolcache\windows\dotnet\dotnet.exe' failed with exit code 1
##[warning].NET 5 has some compatibility issues with older Nuget versions(<=5.7), so if you are using an older Nuget version(and not dotnet cli) to restore, then the dotnet cli commands (e.g. dotnet build) which rely on such restored packages might fail. To mitigate such error, you can either: (1) - Use dotnet cli to restore, (2) - Use Nuget version 5.8 to restore, (3) - Use global.json using an older sdk version(<=3) to build
##[debug]Processed: ##vso[task.issue type=warning;].NET 5 has some compatibility issues with older Nuget versions(<=5.7), so if you are using an older Nuget version(and not dotnet cli) to restore, then the dotnet cli commands (e.g. dotnet build) which rely on such restored packages might fail. To mitigate such error, you can either: (1) - Use dotnet cli to restore, (2) - Use Nuget version 5.8 to restore, (3) - Use global.json using an older sdk version(<=3) to build
Info: Azure Pipelines hosted agents have been updated and now contain .Net 5.x SDK/Runtime along with the older .Net Core version which are currently lts. Unless you have locked down a SDK version for your project(s), 5.x SDK might be picked up which might have breaking behavior as compared to previous versions. You can learn more about the breaking changes here: https://learn.microsoft.com/en-us/dotnet/core/tools/ and https://learn.microsoft.com/en-us/dotnet/core/compatibility/ . To learn about more such changes and troubleshoot, refer here: https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/build/dotnet-core-cli?view=azure-devops#troubleshooting
##[debug]task result: Failed
##[error]Dotnet command failed with non-zero exit code on the following projects : D:\a\1\s\gwsCheckmarx\gwsCheckmarx.csproj
##[debug]Processed: ##vso[task.issue type=error;]Dotnet command failed with non-zero exit code on the following projects : D:\a\1\s\gwsCheckmarx\gwsCheckmarx.csproj
##[debug]Processed: ##vso[task.complete result=Failed;]Dotnet command failed with non-zero exit code on the following projects : D:\a\1\s\gwsCheckmarx\gwsCheckmarx.csproj
Finishing: dotnet publish dotnetcore
I find it weird how locally it runs fine, but on Azure only works without the project reference. Any ideas?
To avoid compatibility issues you should use for .NET Core 3.1 -> .NET Standard 2.1, because .NET Framework also implements .NET Standard, it is possible in some cases to include .NET Framework libraries in .NET Core projects but it is not a good practice.
If your app runs locally, the error can be because the dotnet sdk version that you are using locally is different that the one in the azure agent (from the error it is .NET 5). You can check by running this command in you local: $ dotnet --version
To set an specific version of the dotnet sdk for your project you can execute this command in the root folder of your solution file $ dotnet new globaljson, it will generate a global.json file in which you can set the dotnet sdk version you have in your local.
Other option is set the dotnet version in the agent with Use .NET Core YAML task, and after that run the build.
- task: UseDotNet#2
inputs:
packageType: 'sdk'
version: '3.1.401'
If you want to know the included software in the Azure pipeline VMs take a look at this link: https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=azure-devops&tabs=yaml#software
I have a project in C Sharp which build correctly in my local machine ( as well as in the one from my colleagues ). But when we try to configure the pipeline in Azure, in the step of Nuget restore everything stops and we get an error message stating that package "A" is not compatible with netcore 2.2, as well as package B,C,D,etc.
Why is it possible to see this error in Azure but not in my local? The project is setup to use netcore 2.2 and builds fine in my local machine.
Why is it possible to see this error in Azure but not in my local? The project is setup to use netcore 2.2 and builds fine in my local machine.
This error can occur with an outdated version of nuget. The default version of NuGet running in the VSTS pipeline was not the latest one.
So, to resolve this issue, there is a nuget version installer task which you can run as part of your build step to upgrade the version of nuget running in your build pipeline:
Besides, if update nuget version not resolve this issue, please check the SDK version on the build agent is same as your local, you can use the task Use .NET Core to update the SDK version.
Hope this helps.
I have a Docker build running as a task in an Azure devops build pipeline. Recently I had to add a git submodule to the project which contains a .Net Standard 2.0 library which references Entity Framework Core. Now when I run the build I get the following error message:
CSC : error CS8032: An instance of analyzer
Microsoft.EntityFrameworkCore.RawSqlStringInjectionDiagnosticAnalyzer
cannot be created from
/root/.nuget/packages/microsoft.entityframeworkcore.analyzers/2.2.1/analyzers/dotnet/cs/Microsoft.EntityFrameworkCore.Analyzers.dll
: Could not load file or assembly 'Microsoft.CodeAnalysis,
Version=2.8.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
The system cannot find the file specified.. [/.../MyProject.csproj]
I have tried adding the Microsoft.CodeAnalysis nuget package to the project but that just causes more error messages. I have also tried adding Microsoft.Net.Compilers but that can only build under the full .Net framework so doesn't work for other areas of our pipeline.
The build agent being used is Hosted Ubuntu 1604 which should have the most up to date .NEt core SDK. Everything compiles locally.
Found the problem. I was targeting an old .Net version in the dockerfile.
Old command:
FROM microsoft/aspnetcore-build:2.0.0 as build
New command:
FROM microsoft/aspnetcore-build as build
I am trying to upgrade an Asp.net core application on Debian vm. After I copy the new dlls and test with dotnet path-to-my-app.dll I get this error.
LTTng-UST: Error (-17) while registering tracepoint probe. Duplicate registration of tracepoint probes having the same name is not allowed.
Two further clarify, I am upgrading a self contained app. I first stop the running service and then replace the files with new ones and then just do a
dotnet path-to-myapp.dll
and the above error appears. There was no change in appsettings or any other configuration changes. Do I need to stop any other services as well?
For the general public here is the issue and the solution:
The version on my linux VM was 2.1.5 and my App target version was 2.1.0, However the previous target framework version of installed app was 2.1.0 and it was working fine. I only made a few changes and went on to deploy the new version, first it failed to build with the command "dotnet build --runtime linux-x64" complaining about different frameworks to restore and build. So I first changed the project file to use
<TargetLatestRuntimePatch>true</TargetLatestRuntimePatch>
And after that it failed to run with the above error. Finally I changed the RuntimeFrameworkVersion to 2.1.5 to match my host version AND didn't use the "dotnet build --runtime linux-x64" command but Publish instead. I also read about using the Publish command here:
https://codeblog.dotsandbrackets.com/package-downgrade-issue/
I have a VS2015 project that I have successfully deployed on Azure (via Github) as a web app.
However, after some offline updates, when I deploy, i get the error
The 'System.Net.Http 4.0.0' package requires NuGet client version '3.0' or above, but the current NuGet version is '2.8.60717.93'."
Is nuget 3.0 installed on the web app servers? And how can I use it?
I ended up reverting the System.Net.Http 4.0.0 package to an older version, that works with NuGet version 2.8.60717.93.
NuGet doesn't go on the the app server, it goes on the build server. Make sure your build server has the latest NuGet client. See this SO Answer.