I updated a project from netcoreapp2.2 to netcoreapp3.0 and use Preview8 SDK as well as Microsoft.EntityFrameworkCore.SqlServer, tools, and design.
I can build and run my projects locally just find (VS 2019). But when I try to deploy with Azure DevOps, the Nuget restore gives this error:
NU1202: Package Microsoft.EntityFrameworkCore.SqlServer 3.0.0-preview8.19405.11 is not compatible with netcoreapp3.0 (.NETCoreApp,Version=v3.0). Package Microsoft.EntityFrameworkCore.SqlServer 3.0.0-preview8.19405.11 supports: netstandard2.1 (.NETStandard,Version=v2.1)
Every reference to an EntityFrameworkCore package will result in that error.
I'm setting the .Net Core SDK in the pipeline to Preview8 via a global.json.
I have a NuGet tool installer task, bringing in the latest version, and a Nuget Restore task command running against my solution.
My problem was that I was using the Nuget Restore. Changing it to dotnet restore made the trick.
This problem is caused by an obsolete version of NuGet agent.
Use NuGet Install Tool task (a.k.a. Use NuGet) and setup the agent to the v5.x.
This is a low profile solution.
EDIT: Yay, I have enough rep to comment now.
It turns out the easier fix is to updatethe NuGet package version to the latest (5.3.0) in the "Use NuGet" task.
Not enough rep to comment on Fernando's response but it worked for me.
Edit the pipeline's Agent tasks:
add .NET Core, Display name: dotnet restore, Command: restore
set up other properties pretty much the same as the existing NuGet Restore
remove NuGet restore
Pipeline Nuget restore failing on .Net Core 3.0 Preview 8 project (NU1202)
If you are using the host agent, you should make sure you have install the netcoreapp3.0 on the agent. You could use the task Use .NET Core to install it:
Note check the option Include Preview Versions.
Note: Since netcoreapp3.0 supported by Visual Studio 2019, so, you need to make sure your agent is Hosted Windows 2019 with VS2019.
Hope this helps.
Related
Context
After migrating to version 3.1.420 of dotnetcore SDK (installed automatically by Windows Update) we are facing the problem, that a solution failed to build (on a build server) because nuget restore is unable to restore the package Microsoft.NETCore.App.Host.win-x64.
We have local package feeds configured in nuget.config, the source nuget.org is not and must not accessed directly!
Now I get the following output:
c:\> nuget.exe restore ***.sln -NoCache -NonInteractive -ConfigFile .nuget\NuGet.config
[...]
Errors in C:\build\_work\313\s\***.csproj
NU1101: Unable to find package Microsoft.NETCore.App.Host.win-x64. No packages exist with this id in source(s): ***, ***, ***
NuGet Config files used:
C:\build\_work\313\s\.nuget\NuGet.config
Feeds used:
https://***.com/tfs/***/_packaging/A***/nuget/v3/index.json
https://***.com/tfs/***/_packaging/B***/nuget/v3/index.json
https://***.com/tfs/***/_packaging/C***/nuget/v3/index.json
Environment:
C:\build\_work\313\s>dotnet --list-sdks
3.1.420 [C:\Program Files\dotnet\sdk]
5.0.400 [C:\Program Files\dotnet\sdk]
5.0.408 [C:\Program Files\dotnet\sdk]
Question
Why restore process tries to fetch the nuget package while the content is already part of the SDK installed?
What I've tried?
I've analyzed the behavior of the nuget.exe using Process Monitor (Sysinternals).
I found that the folder c:\Program Files\dotnet\packs\Microsoft.NETCore.App.Host.win-x64\3.1.25\ is accessed but not found, only the folder 3.1.26 exists after update of SDK.
Why restore process tries to access "3.1.25" while "3.1.26" is installed?
On my local machine the restore works as expected. The package is NOT available in my local NuGet cache. Here the folder c:\Program Files\dotnet\packs\Microsoft.NETCore.App.Host.win-x64\3.1.26\ is accessed as expected.
I also tried to reinstall the SDK version. No effect.
Firstly, I highly recommend avoiding nuget.exe restore. If you can, prefer dotnet restore, and otherwise msbuild -t:restore. It's unrelated to the problem you're having here, but you can avoid different types of problems by migrating.
Anyway, the .NET Core SDK 3.1.419 would have had the version 3.1.25 versions of the runtime host, whereas .NET Core SDK 3.1.420 has version 3.1.26 of the runtime hosts. Hence, when the SDK upgraded from 419 to 420, the old version of the runtime host was removed, and the new one installed.
However, as your dotnet --list-sdks output shows, you have the .NET 5 SDK installed. .NET 5 is now out of support, and so it did not receive any update in this month's Patch Tuesday. In May, the last month that the .NET 5 SDK was updated, the latest version of the .NET 3.1 hosting app package was 3.1.25, so when you restore/build an app targeting .NET Core 3.1 with the .NET 5 SDK, the SDK checks for the version of the runtime hosting package it knows about, sees it isn't available locally, and then tells NuGet to download it.
You can either use a global.json to pin that directory's dotnet commands to the .NET 3.1 SDK, or you can install the June 2022 .NET 6 SDK (6.0.301), and then both of them will know that the .NET 3.1 runtime hosting package is version 3.1.26, and therefore should not ask NuGet to download it. Well, unless you uninstall the .NET 3.1 SDK completely and use the .NET 6 SDK to build it.
I know it's confusing. The .NET marketing people chose names that doesn't aid in understanding the difference, but the .NET SDK are build tools that can build any version of .NET equal or lower version, and the .NET runtime is completely independent. As mentioned previously in this answer, you can build .NET Core 3.1 apps with the .NET 6 SDK, the .NET Core 3.1 SDK is not needed (but the runtime will be, unless you publish a "self-contained" app).
Is there a Linux equivalent of LightIngest.exe? The page of the utility does not mention that, search brings no luck either. In case it is not available, what is the preferred way to post ingestion items through CLI in Linux?
There is a .NET Core Kusto.Tools package - it is currently built for Core 2.1 and we will be working on updating it in the coming weeks.
https://www.nuget.org/packages/Microsoft.Azure.Kusto.Tools.NETCore/
Thanks to Vladik's answer I was able to download the package and use the included LightIngest.dll to execute an ingest through my Mac. Here are the steps:
Use nuget to download the Microsoft.Azure.Kusto.Tools.NETCore package installed:
nuget install Microsoft.Azure.Kusto.Tools.NETCore -Source nuget.org -OutputDirectory SPECIFY_OUTPUT_DIRECTORY
Navigate to the directory, and go to the tools subfolder. There you should find LightIngest.dll
Assuming you have dotnet installed (CLI) and SDK (v2.1) you should be able to execute an ingestion:
dotnet ./LightIngest.dll ...
Replace the ... with the Windows equivalent command that Azure Data Explorer Ingestion wizard suggested, and it should start ingesting!
I have a solution with 2 projects:
Client Library project made for .NET Standard 2.0
Test project for .NET Core 3.0
And I created Azure DevOps pipeline which builds and packs this library for DevOps private Nuget feed.
The pipeline contains the following steps:
Use NuGet >= 5.3.1 (added this hoping to solve the issue)
Use .Net Core sdk 3.0.100 (added this hoping to solve the issue)
Restore packages
Build
...
But the process fails at Restore packages step with:
error NU1201: Project [Test Project] is not compatible with netcoreapp2.2 (.NETCoreApp,Version=v2.2). Project [Test Project] supports: netcoreapp3.0 (.NETCoreApp,Version=v3.0)
So how can I set up CI/CD for .Net Core 3.0?
I DO NOT use YAML - I hate that thing.
I tried "Use Nuget" to force the pipeline to use the latest Nuget.
I also tried to for it using the latest .Net Core 3.1.x.
All this doesn't help.
What helped was the re-creation of the test project. Now the pipeline works!
Got this error today after upgrading VS2017 to v15.8.2 and trying to build my dotnet core project (target framework .NET Core 2.1):
Severity Code Description Project File Line Suppression State
Error NETSDK1061: The project was restored using
Microsoft.NETCore.App version 2.1.3, but with current settings,
version 2.1.3-servicing-26724-03 would be used instead. To resolve
this issue, make sure the same settings are used for restore and for
subsequent operations such as build or publish. Typically this issue
can occur if the RuntimeIdentifier property is set during build or
publish but not during restore. For more information, see
https://aka.ms/dotnet-runtime-patch-selection.
What to do?
Found out solution:
Uninstall .NET Core SDK 2.1.401, that came with vs2017 v15.8.2 and install it again using an installer from the .NET Downloads page.
Source: #joshuadavidson https://github.com/dotnet/cli/issues/9897
Also quote #peterhuene:
"It's come to my attention that VS 15.8.2 did not include the correct,
final build of the 2.1.401 SDK. We are working on resolving this
issue. In the meantime, uninstalling the 2.1.401 SDK installed by
Visual Studio and installing the SDK from the .NET Downloads site
should correct the issue."
Update, September 7th 2018:
or simply upgrade to VS2017 v15.8.3, where the problem is resolved:
"Visual Studio 2017 version 15.8.2 contained a pre-release build of
.NET Core SDK 2.1.401 that is incompatible with Visual Studio. We have
corrected this issue with Visual Studio 2017 version 15.8.3."
Is there a defined way of downgrading a solution to a lower version of the .net Framework.
Try to target .NET Framework 4.0 in your solution first.
Right click on your project-> Properties->Application panel. You should see it there. After setting your target framework you have to compile and address all possible framework specific scenarios.
In Visual studio you should set the target to be Framework 4.0 (msdn). And then fixup the errors for any code manually that relies on 4.5
If you have downloaded any packages using Nuget while your project was a 4.5 project, you need to manually remove the packages and install the pages again after you have changed your project to 4
First Update the packages and this will change many of packages using the command PM> update-package
You can remove the packages using PM > uninstall-package packageName -force
Install the package back using PM>install-package packageName
You can check to make sure all your nuget packages are 4.0 by looking at the packages.config file in the root of each project.