Dajbych.net

It is the start of a new era of mak­ing soft­ware in the Mi­crosoft ecosys­tem. This restart pushes the .NET where it was orig­i­nally in­tended to be. Its pur­pose is sim­ple – reach­ing ev­ery plat­form and ev­ery op­er­at­ing sys­tem with C# lan­guage from Vi­sual Stu­dio. So why did it take so long? Well, this goal is ev­ery­thing but sim­ple. Only C++ lan­guage has been able to do that. The .NET is evo­lu­tion of C++ & COM world. To­day .NET fi­nally sup­ports na­tive com­pi­la­tion.

Prior .NET era: C++ & COM

C++ world has sev­eral disad­van­tages. There is no mem­ory man­age­ment, no com­mon type sys­tem and MFC is not mul­ti­plat­form. None li­brary is portable to other pro­ces­sor ar­chi­tec­ture than it was com­piled to.

.NET Framework era: JIT & GC

The .NET Frame­work was in­tended to fix disad­van­tages of C++ & COM world. It was orig­i­nally named COM 2.0. It has been very suc­cess­ful in do­ing that. Just-in-time com­pi­la­tion pro­vides porta­bil­ity of li­braries among mul­ti­ple pro­ces­sor ar­chi­tec­tures. Garbage col­lec­tor makes pro­gram­ming dra­mat­i­cally eas­ier. And fi­nally task-based asyn­chronous pro­gram­ming pat­tern cre­ates a thread ab­s­trac­tion layer, so waste of threads is no longer nec­es­sary (and bat­tery drain does not take a place).

Some­one would say that .NET Frame­work was not mul­ti­plat­form. It ac­tu­ally was – SS­CLI (for Win­dows, OS X and FreeBSD sys­tems), Dot­GNU (for Linux, Windows, So­laris, BSD and OS X sys­tems and for x86, s390, SPARC, HPPA, Stron­gARM a Pow­erPC ar­chi­tec­tures) and Mono (for An­droid, Linux, BSD, OS X, Win­dows and So­laris sys­tems and x86, x64, s390, SPARC, Pow­erPC, MIPS, ARM and IA-64 ar­chi­tec­tures). Only one thing was wrong – Win­dows SDKs were em­bed­ded into .NET Frame­work. It was very hard to port Win­dows ren­der­ing models (GDI+ and Di­rectX) or web server API (IS­API) to other op­er­at­ing sys­tems. More­over, Mi­crosoft did not help but rather suited for soft­ware patents vi­o­la­tions.

The .NET Frame­work sup­ports many plat­forms (mi­cro­con­trollers, smart­phones, PCs or servers), there­fore there is no longer a sin­gle .NET Frame­work. Since dif­fer­ent pro­files have ex­isted it has not been pos­si­ble to cre­ate a sin­gle li­brary that could be ref­er­enced by all of .NET Frame­work pro­files. (The first at­tempt – Portable Class Li­braries – has never ac­tu­ally solved this prob­lem.)

.NET Core era: native & multiplatform

.NET Core is full .NET Frame­work without Win­dows SDKs plus some great fea­tures. What does it of­fer?

• com­mon type sys­tem
• com­mon ex­cep­tion han­dling
• com­mon pack­ag­ing sys­tem
• mem­ory man­age­ment
• com­pi­la­tion to byte­code (with de­pen­dency on run­time)
• com­pi­la­tion to na­tive code (without porta­bil­ity)

Let’s clar­ify what the porta­bil­ity in con­text of .NET means:

• Just-in-time com­piler (JIT) can ex­e­cute any byte­code as­sem­bly. It means that tar­get­ing Any CPU makes the as­sem­bly ex­e­cutable on any op­er­at­ing sys­tem or pro­ces­sor ar­chi­tec­ture which .NET Core (run­time) is im­ple­mented for.
• A na­tive ap­pli­ca­tion is a sin­gle ex­e­cutable. It does not de­pend on any run­time. It means that you do not have to check for ex­is­tence of .NET Core (run­time) on tar­get ma­chine. The trade­off is porta­bil­ity to other plat­forms.
• An as­sem­bly can ref­er­ence an­other as­sem­bly orig­i­nally writ­ten in an­other .NET lan­guage. It means that C# ap­pli­ca­tion can ref­er­ence a li­brary writ­ten in F# and vice versa.

Which great fea­tures was I men­tion­ing?

• com­piler as a ser­vice (Roslyn)
• em­bed­ded web server for ASP.NET Core apps (Kestrel)
• open-source soft­ware de­vel­op­ment (via GitHub)
• sup­port by Mi­crosoft and Red Hat

Visual Studio

Vi­sual Stu­dio is an IDE at no cost for all users. There are two ma­jor ver­sions – Vi­sual Stu­dio (for Win­dows) and Vi­sual Stu­dio Code (for Linux, macOS, and Win­dows). While Vi­sual Stu­dio is a very com­plex tool with its own source con­trol, bug track­ing and project plan­n­ing sys­tem, Vi­sual Stu­dio Code is much more lightweight. It is a text ed­i­tor with syn­tax high­light­ing, In­tel­liSense, de­bug­ging and Git ver­sion con­trol. All SDKs by Mi­crosoft are ex­tend­ing Vi­sual Stu­dio by project tem­plates, li­braries and tools.

.NET Standard

The byte­code – CIL – is stan­dardized in ECMA 355 stan­dard. Sim­i­larly, li­braries – BCL – are stan­dardized in CoreFX set of APIs. For ex­am­ple, the net­work­ing stack is com­mon to many de­vices and plat­forms, but all op­er­at­ing sys­tems have dif­fer­ent net­work­ing syscalls. The Htt­p­Client class pro­vides a nec­es­sary ab­s­trac­tion. The .NET Stan­dard de­fines meth­ods that Htt­p­Client has. The doc­u­men­ta­tion de­scribes its proper be­hav­ior.

Web development

Clas­si­cal ASP.NET web ap­pli­ca­tion runs on IIS (a web server) which is a com­po­nent of Win­dows Server. Mi­crosoft did not sup­port run­n­ing ASP.NET apps on other op­er­at­ing systems than Win­dows. That has been changed. De­pen­dency on IIS was re­placed by Kestrel web server.

Kestrel is part of ASP.NET Core. ASP is (in con­text of .NET Core) a web SDK. It is writ­ten in .NET Core and is op­ti­mized for high per­for­mance, be­cause garbage col­lec­tion and string im­mutabil­ity is some­thing what hardly fits with per­for­mance net­work­ing. Kestrel runs ev­ery­where where .NET Core (run­time) runs (Win­dows, Win­dows Server, ma­cOS, RHEL, Ubuntu, De­bian, Fe­dora, Cen­tOS and open­SUSE). Nowa­days only byte­code com­pi­la­tion is sup­ported. Na­tive com­pi­la­tion will be sup­ported later.

Windows development

The tra­di­tional .NET Frame­work will be still sup­ported. It also im­ple­ments .NET Stan­dard, so you can eas­ily cre­ate a li­brary tar­get­ing both .NET Frame­work and .NET Core. While .NET Frame­work is up­dated via Win­dows Up­date, .NET Core is up­dated with the app (in case of na­tive com­pi­lation) or by sys­tem ad­min­is­tra­tor by up­dat­ing the .NET Core pack­age (in case of byte­code com­pi­la­tion).

At this time, there are no SDKs for .NET Core to tar­get Win­dows desk­top, be­cause these SDKs are part of the .NET Frame­work (Win­dows Forms and WPF). The SDK for Win­dows Store apps is called Uni­ver­sal Win­dows App De­vel­op­ment Tools.

Future development

The first patch (1.0.1) is sched­uled for ar­rive in Au­gust 2016. It will focus on per­for­mance im­prove­ments and bug fixes.

The first mi­nor up­date (1.1.0) will change the build sys­tem from DNX to MS­Build, which is be­ing ported to .NET Core. This up­date is sched­uled to Q4 2016 / Q1 2017.

The first ma­jor up­date (2.0) could be re­leased in the mid­dle of 2017. It will unify all com­mon APIs and classes across .NET Frame­work, UWP, Xa­marin.iOS and Xa­marin.An­droid into .NET Stan­dard 2.0.