Is .NET for Universal Windows Program a subset of .NET Core?

Question

My confusion is that I read that the UWP uses .NET Core, but there is a separate documentation API ".NET for UWP" here . In addition, I can not find some of the features in your .NET Core UWP project.

Answer 1

.NET Core is a cross-platform subset of .NET that can be used to create applications for Windows, Linux, Mac, and yes, UWP.

UWP Api is also a subset of the .NET API that can run on the .NET Core. He also has a number of API, which is unique to the UWP. UWP applications can be basic .NET applications, but the converse is not necessarily true. Not all .NET core applications - it UWP applications.

As well as an API for .NET Core, which applies only to Linux or Mac.

Answer 2

Direct response: No, it is not so!

Long answer: it's complicated

• uap10.0 (the UWP) and netcoreapp1.0 (cross-platform .NET Core) are competing models of applications / SDK / Platforms (any terminology that Microsoft chooses to mention later). I use here the notation of the target platform (technical terminology), to avoid confusion over the term ".NET Core". uap10.0 focuses on the applications of the user interface based on Windows, and netcoreapp1.0 is basically a shell application to cross-platform systems (which, like any program can run servers, such as ASP.NET).
• The question about the superset / subset is complicated. They overlap. uap10.0 implements netstandard1.4 , and netcoreapp1.0 implements netstandard1.6 (which is a strict superset of netstandard1.4 ) (standard platform documentation platform standard documentation ). However, both models applications are added to it, significant additional libraries (eg, uap10.0 adds libraries Windows.* , And the library to netcoreapp1.0 called Microsoft.NETCore.App ( NuGet ) adds such things as immutable collections, networking opportunities, file system, cryptography and other things that are not standardized (yet) in .NET implementations).
• Terminology ".NET Core" generally corrupt. CLR, which triggers uap10.0 / UWP, was obtained from Silverlight, which designated the execution time coreclr . Modern cross-platform netcoreapp1.0 using CLR, obtained from UWP project. The same is true for libraries, which in all cases are based on System.Runtime instead mscorlib .

Update August 2019

• To date, there is still the same as the difference between uap10.x and netcoreapp3.x . Nevertheless, they both realize netstandard2.x (and just as Mono and unity). A subset netstandard2.x an important API surface, making the most of the packages nuget compatible with both.
• I understand that most of the surface winrt API will be available to netcoreapp3.x enabled COM (including winrt com and traditional COM). This makes the intersection netcoreapp3.x very significant. It is scheduled for late 2019.
• netcoreapp3.0 will also support WPF and WinForms .NET Framework and other libraries. They will never be maintained uap10.0 .
• UWP technology stack (which consists of several levels) now supports packing / storage processing for all types of applications (not just uap / winrt once).
• The really interesting thing will be in .NET 5. Java, interaction with WebAssembly and Swift, AOT compilation and MonoVM. Available surface space of the library and its location will explode.

Answer 3

No, UWP - it's a great api, which is aimed at a different model windows, replaced most of the traditional winapi. You get dependent .NETCore, because the project templates in VS choose it. For a good reason, you can get the U in the UWP (Universal Windows Platform) only .NETCore, devices such as phones and Hololens, do not have the full version of the .NET framework. Trying to be competitive in mobile applications has been the main reason for the UWP.

UWP - api is based on the COM, the main reason why it works with languages ​​such as Javascript and C ++. Otherwise, very well hidden, traditional COM type library format has been replaced by .winmd, a format that is largely based on the .NET metadata format. It can emulate the functions that COM can not support, such as generics, static methods and implementation inheritance. The language projection needed to get this emulation is built into the CLR. Not only that they can do to make exceptions better.

You can also use UWP api in a desktop application. Microsoft does not encourage it, so you do not get any help from the project template. It is easy to fix with a text editor, add the <TargetPlatformVersion>10.0.10586.0</TargetPlatformVersion> in your .csproj file, and now you can use the Project> Add Reference and select the contract UWP. Conveniently use space device names.