.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).