For a .Net Core 2.1 project, Why does Nuget restor

Question

If a package is not available for .Net Core how do we enforce strict .Net runtime version checking during, Install-Package command?

Install-package command, why does Visual Studio even, restores .Net 4.6.1 version, just to give a runtime error at later stages!

I'm sure VS team has thought about it and there must be a reason! As well as a mechanism to validate & strict runtime version checking during Install-Package.

Warnings:

Warning NU1701 Package 'Microsoft.AspNet.Identity.Core 2.2.2' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETStandard,Version=v2.0'. This package may not be fully compatible with your project.

Edit: I just took one of the full .net framework packages, as example.

Intention was to ask how to prevent it from happening in Nuget package manager.

Warning NU1701 Package <any full .net framework package> was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETStandard,Version=v2.0'. This package may not be fully compatible with your project.

Answer 1

It's explained by Microsoft in this GitHub issue. Quoting the relevant part:

[...]

Whenever you use NuGet packages that go through the compat shim you'll get a warning like this:

Warning NU1701: Package 'Huitian.PowerCollections 1.0.0' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETCoreApp,Version=v2.0'. This package may not be fully compatible with your project.

We've made sure you get this warning every time you build (rather only during package restore) to ensure you don't accidentally overlook it.

The idea here is that we have no way of knowing whether the .NET Framework binary will actually work. For example, it might depend on WinForms. To make sure you don't waste your time troubleshooting something that cannot work, we let you know that you're potentially going off the rails. Of course, warnings you have to overlook are annoying. Thus, we recommend that you test your application/library and if you're convinced everything is working fine, you suppress the warning:

[...]

So if the package works, then you can suppress the warning. If it doesn't, you'll have to use a different package or wait for the package to support your target framework.