Assemblies that “target” (are compiled against/for) .NET Framework (1.0-4.8) may use APIs (types, methods) that are not present in .NET Standard or .NET Core.
So if you have a project that targets .NET Standard or .NET Core, and you want to add a reference to an assembly that targets .NET Framework, it may be that the assembly will throw exceptions at runtime, because it’s missing method overloads or types. Those types are present in the Framework DLLs, but not in the .NET Core runtime assemblies.
Now if you know (through interpreting the code or through testing, preferably both) that the Framework-targeting assembly doesn’t use APIs that are missing from .NET Standard or .NET Core, you’re fine (for the difference, see What is the difference between .NET Core and .NET Standard Class Library project types?).
The fix (but not really)
If it’s an assembly that’s chucked in a
lib folder in source control, you can add an assembly reference:
<Reference Include="../lib/path/To/Dll.dll" />
If it’s a NuGet-packed dependency, you can install it and override the warning:
<PackageReference Include="Some.Framework.Package" Version="1.0.0" NoWarn="NU1701" />
The fix (for real this time)
Recompile the assembly to target .NET Standard 2.0, and package and distribute that through NuGet.