C# – Is ConfigurationManager.AppSettings available in .NET Core 2.0

I'll answer your second question first:

I have a library that targets .Net 2.0, .Net 4.5, and UWP. Targeting UWP required creating a new VS project and linking all the existing files, which is a huge pain. Now someone is telling me it doesn't work for PCL, and from the sound of it I have to do it AGAIN for .Net Standard!?)

If I want to write a library that's usable to as large an audience as possible, which one (or more than one) of these do I need to use?

Short answer: you should target netstandard. Use the lowest version that has all the APIs you need. You can use a tool like API Port to check your existing project for compatibility with a given netstandard version.

Unfortunately, this approach will leave behind older platforms, in your case, .NET 2.0. If maintaining .NET 2.0 support is necessary, then you'll need a separate project (with linked files) to build a separate .NET 2.0 assembly.

On to the details...

What's the difference!?

• .Net Standard (netstandard) - this is the new cross-platform BCL API. It's a "standard" in the sense that it's just an API definition and not an implementation. The idea is that you can compile your library to (a version of) this API and it will run on any platform that supports that version.
• .Net Core - you can think of this as a reference implementation of netstandard (with a few extra bits). It is a cross-platform implementation of that API. It is possible that UIs and other frameworks may build on it, but for now its only sure foothold is acting as the platform of choice for ASP.NET Core. [Side note: for historical reasons, ".NET Core" is completely different than the netcore NuGet target; when you're in a NuGet context, netcore means "Windows 8/8.1/10"].
• .Net Portable and Portable Class Libraries - Portable Class Libraries (PCLs) are a least-common-denominator approach to providing a cross-platform API. They cover a wide range of target platforms, but they are incomplete and not future-proof. They have essentially been replaced by netstandard.
• .Net Compact - This is a completely different .NET framework with its own unique API. It is completely incompatible with any other framework, PCL, or netstandard version; as such, it is much more difficult to support than any other platform. However, it is still used on devices with tight memory constraints.
• Universal Windows Platform - This was a Win10-era merging of the API between Windows Phone and desktop, allowing Windows Store apps/libraries to be written for both platforms. This has essentially been replaced by netstandard.

When should we use one over the other?

The decision is a trade-off between compatibility and API access.

Use a .NET Standard library when you want to increase the number of applications that will be compatible with your library, and you are okay with a decrease in the .NET API surface area your library can access.

Use a .NET Core library when you want to increase the .NET API surface area your library can access, and you are okay with allowing only .NET Core applications to be compatible with your library.

For example, a library that targets .NET Standard 1.3 will be compatible with applications that target .NET Framework 4.6, .NET Core 1.0, Universal Windows Platform 10.0, and any other platform that supports .NET Standard 1.3. The library will not have access to some parts of the .NET API, though. For instance, the Microsoft.NETCore.CoreCLR package is compatible with .NET Core, but not with .NET Standard.

What is the difference between Class Library (.NET Standard) and Class Library (.NET Core)?

Compatibility: Libraries that target .NET Standard will run on any .NET Standard compliant runtime, such as .NET Core, .NET Framework, Mono/Xamarin. On the other hand, libraries that target .NET Core can only run on the .NET Core runtime.

API Surface Area: .NET Standard libraries come with everything in NETStandard.Library, whereas .NET Core libraries come with everything in Microsoft.NETCore.App. The latter includes approximately 20 additional libraries, some of which we can add manually to our .NET Standard library (such as System.Threading.Thread) and some of which are not compatible with the .NET Standard (such as Microsoft.NETCore.CoreCLR).

Also, .NET Core libraries specify a runtime and come with an application model. That's important, for instance, to make unit test class libraries runnable.

Why do both exist?

Ignoring libraries for a moment, the reason that .NET Standard exists is for portability; it defines a set of APIs that .NET platforms agree to implement. Any platform that implements a .NET Standard is compatible with libraries that target that .NET Standard. One of those compatible platforms is .NET Core.

Coming back to libraries, the .NET Standard library templates exist to run on multiple runtimes (at the expense of API surface area). Conversely, the .NET Core library templates exist to access more API surface area (at the expense of compatibility) and to specify a platform against which to build an executable.

Here is an interactive matrix that shows which .NET Standard supports which .NET implementation(s) and how much API surface area is available.