We Keep Coding

C# - Can net6.0 project use a package reference of .net framework, for example, .net472?

I have a net6.0 SDK-style project and I want to use a library which seems to be only released to .net framework. After I added the reference, I got a warning as below. And for sure I can't use any classes from the lib in my code.
Package 'xxx' was restored using '.NETFramework,Version=v4.6.1, .NETFramework,Version=v4.6.2, .NETFramework,Version=v4.7, .NETFramework,Version=v4.7.1, .NETFramework,Version=v4.7.2, .NETFramework,Version=v4.8' instead of the project target framework 'net6.0'. This package may not be fully compatible with your project.
I'm new to C#. Does it mean that each lib only works for specific .net versions? Library developers declare and compile their code for the supported .net versions and publish to nuget. When we refer to a nuget lib, nuget will try to find the dll which matches our .net version and throw the above warning if not found.
That is to say, to be compat with the library, I have to downgrade my project to net472?

Yes, that is correct. Each library is typically compiled for specific versions of .NET.
If you want to use this library, you will need to downgrade your project to target one of the supported .NET Framework versions.

Does it mean that each lib only works for specific .net versions?
It is more nuanced than that; usually, libraries are perfectly happy with lower versions - meaning: if I target net5.0 from a library, and your application is net7.0: that's fine (with the caveat that even minor revisions can - but rarely - break something, if it was depending on functionality that has changed, perhaps because it was a bug - or some other implementation detail).
However, there is a hard break between .NET Framework and .NET Core (now just .NET); a .NET Core / .NET application cannot reliably consume a library that only targets .NET Framework, as .NET Framework is a fundamentally different framework than .NET Core / .NET.
In this scenario, libraries can do a few things to help you:
they can target some variant of .NET Standard, which is the subset of APIs that should work correctly on both .NET Framework and .NET Core / .NET (and other platforms that implement .NET Standard, such as Unity, Mono, Xamarin, etc as)
they can multi-target, which is to say: in the nupkg they can include multiple assemblies, perhaps a net472 target, a net6.0 target, and maybe one or two others
(the second option is more common than the first; .NET Standard is fading into the background now)
If the library you're using only supports .NET Framework, then indeed that won't work from .NET Core / .NET; you have three options:
limit yourself to .NET Framework (I do not recommend this option)
see if the library can be updated to use .NET Core / .NET (by contacting the maintainers, and possibly even proposing the changes yourself)
use a different library

Upgrading class library project to .net standard 2.1 where this has been referenced by .net framework 4.X projects

We are upgrading our solution of multiple projects. Starting with one class library which is been referenced by 13 projects. I need to upgrade my class library project .NET Framework 4.5 to .NET Standard 2.1.
Here the problem is:
This class library is being referenced by projects of .NET Framework 4.5 and its throwing error that it can't access .NET Standard 2.1 lib
Project 'abc.csproj' targets 'netstandard2.1'. It cannot be referenced by a project that targets '.NETFramework,Version=v4.5'.
How to resolve this problem? Upgrading all those 13 projects is not possible at the same time.
EDIT:
Following comments, if I convert lib to .netstandard1.1 then errors start coming in the library itself:
After downgrading lib to .netstandard1.1, following on
NetStandard 1.4 does not allow decorating class with [DataContract]. I saw this post and added this package System.Runtime.Serialization.Primitives:
I even added reference to older dll but, still getting error:

Adding answer as we've iterated through the comments. At first OP wanted to change framework of library to .NET Standard 2.1 while having other apps under .NET Framework 4.5.
Unfortunately, this is not possible. As specified in the official documentation, .NET Standard 2.1 is not following along with .NET Framework. Latest you can get is .NET Standard 2.0 with .NET Framework 4.6.1. Solution for this issue is to downgrade common library project to .NET Standard 1.1, other app projects should be able to link to this.
Next iteration (after downgrading to .NET Standard 1.1) brought issue related to "unknown classes" and VS/compiler asking for adding reference. There was already existing question, answer is to download NuGet package related to the data serializers.
If your code in end-applications are also using classes/attributes from the affected assembly, you must make a cleanup. So that all code references the only single version of source. It is not possible to have one Attribute taken from Nuget and check for "same attribute/same name" but from different source (system assembly -> System.Runtime.Serialization).

visual studio generate .net dll files

im building an app using c# (not my first. other projects i dont have this problem). this one i included nuget package json
the problem that VS generates too many .dll files in my bin/debug folder (with exe). i don't want these dll files but it seems like the exe doesn't run without them (i coppied the exe to another path and run it)
when i search on the internet all the details about merging using some merge tool but my problem is related VisualStudio in the setting i believe?

This happens when you include a library which targets .NET Standard 1.5 or higher, from a project which targets .NET Framework 4.7.1 or lower.
The .NET Platform Standard table hints at this: it claims that .NET Framework 4.6.1 supports .NET Standard 1.5 or higher, but there's a footnote:
The versions listed here represent the rules that NuGet uses to determine whether a given .NET Standard library is applicable. While NuGet considers .NET Framework 4.6.1 as supporting .NET Standard 1.5 through 2.0, there are several issues with consuming .NET Standard libraries that were built for those versions from .NET Framework 4.6.1 projects. For .NET Framework projects that need to use such libraries, we recommend that you upgrade the project to target .NET Framework 4.7.2 or higher.
One of these issues is that you'll get a lot of extra DLLs, apparently because .NET Framework 4.6.1 only has partial support for .NET Standard 1.5.
The solution is for your project to target .NET Framework 4.7.2, or .NET Core.

With the final release of netstandard 2.0 and netcore 2.0, why we care to build netstandard2 library while we can use the full framework 4.6.1

.Netstandard2 is released final with .Net Core 2.0 and vs2017.3 with nuget4.3 and API surface cover 32k (except 41 class) and full cover net461
Quoting from Announcing .NET Core 2.0
You can now reference .NET Framework libraries from .NET Standard libraries using Visual Studio 2017 15.3. This feature helps you migrate .NET Framework code to .NET Standard or .NET Core over time (start with binaries and then move to source). It is also useful in the case that the source code is no longer accessible or is lost for a .NET Framework library, enabling it to be still be used in new scenarios.
We expect that this feature will be used most commonly from .NET Standard libraries. It also works for .NET Core apps and libraries. They can depend on .NET Framework libraries, too.
The supported scenario is referencing a .NET Framework library that happens to only use types within the .NET Standard API set. Also, it is only supported for libraries that target .NET Framework 4.6.1 or earlier (even .NET Framework 1.0 is fine).
So, in .netcore2 environment we can continue build/use Full .Net Framework as we did many years without the need to switch to .netstandard2 libraries.
With multi target project ,(net64;netstandard2), we get .net standard 2.0 out of box free (zero time effort) with the same API coverage.
Can you share your experience regarding: Can we continue build Full Framework 4.6.1 class library and use it in .netcore2? what is the limitation?

When you build a .NET Framework library, you can only use 4.6.1 with .NET Standard. If you want to use a newer API that is in e.g. netstandard2.0 or .NET 4.7, you'd need to retarget your library to 4.7, which then cannot be used by netstandard2.0 / netcoreapp2.0 projects. Effectively, you are locked into .NET Framework version 4.6.1 and can (/should) never update it to a newer version. (Of course, there is a workaround involving disabling the implicit fallback definition and manually setting AssetTargetFallback in the consuming project, but it requires manually editing the .csproj file and instructing all package consumers to do so).
Furthermore, the compatibility layer does not protect against using APIs that are not implemented on netstandard so a consuming project may get exceptions about missing types, methods, assemblies etc. Only when you target .NET Standard, your library is guaranteed to work on .NET Standard conformant platforms.
A practical limitation currently is that referencing .NET Framework library projects(!) (not NuGet packages) from .NET Core is not possible / only works with specific setups and workarounds (you will get an incompatible target framework warning).

.net core & .net framework in the same team

Our development team has many .net framework 4.6 projects (VS 2015).
We want to start a new .net core project to eventually deploy on linux.
We have installed VS 2017 and the .net core 2.0 preview.
But how can we reuse the existing library projects in this new one ?
We research but it is not clear for us :
- we need to change the target of the old projects from ".Net Framework 4.6" to ".NetStandard 1.x" ? (and solve the incompatibility)
- or we can use them like that ? (but how?)
Thanks

Microsoft publishes official guidelines for the porting process: https://learn.microsoft.com/en-us/dotnet/articles/core/porting/
To summarize:
Deal with your dependencies (by migrating them), recursively
Retarget your projects. Applications move to .NET core, libraries move to .NET Standard, where possible.
Use some helpful tooling to verify your ports
Test
So, to share things between .NET Framework and .NET Core, your libraries should target .NET Standard, as much as possible. Otherwise, you could possibly share the code and have to do multiple builds - build once targetting .NET Framework and again targetting .NET Core.

You can use/reference your old projects only if you target Full Framework in your new projects (which is not the case if you are going to run them on Linux).
If you started with preview you should convert you old projects to .Net Core projects and either target .NET Core 2.0 Preview or NetStandard 2.0 Preview. If you are not going to reference/use your old projects outside your application it might be better to target .NET Core 2.0 Preview because it might provide more API than NetStandard 2.0 Preview.