Difference between .Net Core, Portable, Standard, Compact, UWP, and PCL?

Solution 1:

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.

Solution 2:

As linked in the comments, there is already a description by Microsoft that outlines all of this information. However, by your response, it seems as though you didn't fully understand the entire thing. It's very long, so here's (hopefully) a tl;dr version.

We'll start with the following table from the above link, and hopefully this will clear up some of the confusion:

A brief overview for other pople who find this later: The .NET libraries have gone over a lot of changes and ports over its 15 years of existence. In that time, many smartphones are now nearly as powerful as some desktops that were in use back in 2001. In that intermin, subsets of the .NET framework were created (and quickly abandoned) for use in different platforms. With Satya Nadella's new approach to making .NET as wide-reaching of a platform as possible, things needed to change.

Being a 15 year old technology, things needed to be improved. .NET Core has been worked on since 2014 as a complete overhaul of the .NET architecture. It has been rewritten from the ground up as a new version of the .NET language. One of the goals of Core was to enable cross-platform deployment. Whether it's an app to run on an iPhone/Android/XBox One, or a website that can be hosted in IIS, or on a Linux box, .NET Core has you covered. It does this by several different ways, including not requiring the .NET Framework to be installed on the machine, and will instead package the necessary libraries with your solution.

Most notably with .NET Core is the drastic changes to ASP.NET. The old System.Web is completely gone and rewritten to be as performant as possible with impressive results. The separate WebApi controllers are gone, as everything is done within a single controller. The entire process is now opt-in as opposed to defaulting to allow things you might not want to.

However, we as developers will want to migrate some applications eventually, so how can we be sure that the code we've already written hasn't had several little minor name changes to methods thus breaking the compilation of giant solutions? In comes the .NET Standard. This is a set of APIs that must be implemented in order for your platform to call itself ".NET".

As the basic .NET Framework we've been working with for years is well-established, it was used as the basis for what the Standard will encompass. However, everything isn't included, as what would be the point? So the Standard is only what common APIs will exist between the various types of the .NET platforms. You will not eventually be writing code in ".NET Standard".

Xamarin (included in the above table) was purchased by Microsoft in 2016, and that technology was used to help build (or at least inspire) .NET Core to be cross-platform. It still exists as a tool, but in the same veins as it was used in the past. According to the table, it will be .NET Standard 2.0 compliant in the vNext release. However, it's target audience will not change.

To directly answer your question, if you want to write an application with the widest possible, single deploy solution, you would want to use .NET Core. However, if you're using a library that is currently built upon .NET Framework 2.0 and 4.5, then you will be stuck using .NET Framework and having that separate UWP solution for that target.

If it provides something that you can call through a Web API call, you could have that running on your server in .NET Framework, and have a single solution in .NET Core to deploy to your end users. If it is integrated to your code, you're unfortunately out of luck until a .NET Core update is provided.

Hopefully this has cleared up some of the confusion among the different technology names.

EDIT

After some clarification on your specific situation, I can clear things up for you. You can not make a single solution that will target both .NET Framework and .NET Core. The compile in completely different ways, with different underlying technology, so this is the same situation as trying to use your .NET 4.5 version in a .NET 2.0 solution.

However, there are tutorials out there to allow for you port your project to Core. For the most part, just copy the class bodies into your .NET Core solution, and most stuff will work correctly. There are some pieces that have been abandoned, some that haven't been completely 100% fleshed out yet (not for your case, but Entity Framework doesn't have all the same features for example). There are also some calls that have changed a little bit.

The good new is that moving forward, .NET Core will give you the broadest reach possible. .NET Framework is not going away, but it and Core will be much more in sync with each other.

The other benefit to .NET Core is that it uses an iterative approach to deployment so you won't be waiting 2 years for the next major upgrade. With everything being delivered through NuGet, you'll have a much faster turn-around on improvements and new features.