Dajbych.net

.NET 5.0 is here. It is a suc­ces­sor of .NET Frame­work 4.8 a .NET Core 3.1. It means that Con­sole, Win­dows Forms and WPF apps can be now packed with its own run­time. It was al­ways pos­si­ble to em­bed .NET Run­time in­staller to the ap­pli­ca­tion in­staller it­self, but the new ap­proach means that mul­ti­ple apps does not share and there­fore does not de­pend on a sin­gle .NET Run­time. You can develop on lat­est bits without af­fect­ing others. Im­pli­ca­tions are huge.

Different approach

When new hard­ware al­lowed new fea­tures, new Win­dows ver­sion must sup­port it hence new ap­pli­ca­tion re­quires it. Re­quire­ments of new ap­pli­ca­tions in­creased salles of new hard­ware which in­creased Win­dows salles au­to­mat­i­cally. The orig­i­nal busi­ness model of Win­dows was sim­ple. Win­dows was the op­er­at­ing sys­tem and the Base Class Li­brary (BCL) in a sin­gle pack­age.

.NET Frame­work jeop­ar­dized this busi­ness model. It was a foun­da­tion which al­lowed ap­pli­ca­tions to run across many ver­sions of Win­dows, so new hard­ware was no longer needed as much. Even the lat­est .NET Frame­work 4.8 sup­ports Win­dows 7 SP1 and if you stick with .NET Frame­work 4.0, you can run on Win­dows XP. All your li­braries your ap­pli­ca­tion needs are no longer part of Win­dows (which de­vel­op­ers are not al­lowed to re­dis­tribute) but they ex­ist as NuGet pack­ages in­stead (which are meant to be re­dis­tributable). The only de­pen­dency is GUI, but Chromely/Bla­zor, Uno Plat­form and MAUI have po­ten­tial to re­place it.

The old Win­dows busi­ness model was no longer sus­tain­able any­more. The lat­est at­tempt was Win­dows Run­time, which was port of .NET Run­time with a dif­fer­ent garbage col­lec­tor (with a high prob­a­bil­ity based on ref­er­ence count­ing) and AOT com­pi­la­tion (in Mi­crosoft Store). New Win­dows as a ser­vice busi­ness model is much more com­pat­i­ble with .NET it­self. An­other rea­son for op­er­at­ing sys­tem as a ser­vice is des­per­ate need of the lat­est ver­sion of ev­ery­thing what is en­gaged in net­work com­mu­ni­ca­tion. Se­cu­rity is so hard.

In the middle of a long run

.NET 5.0 is not the fi­nal idea. In fact, it is some­where in the mid­dle of what Mi­crosoft is try­ing to achieve. De­vel­op­ers in fol­low­ing ar­eas are lucky:

• Con­sole ap­pli­ca­tions

• Win­dows Ser­vices

• Win­dows Forms

• WPF

• ASP.NET

• ASP.NET Core

On the other side, de­vel­op­ers in these ar­eas are out of luck so far:

• UWP

• Xa­marin.Forms

• Xa­marin.An­droid

• Xa­marin.iOS

• Xa­marin.Mac

• Xa­marin.tvOS

I have ex­pected it for rea­sons I will de­scribe be­low, but many de­vel­op­ers don’t know whether Mi­crosoft is still cares of them or leav­ing them be­hind.

In tech­ni­cal terms, this is what we have:

• BCL im­ple­men­ta­tion for Win­dows API,

• Run­time (Ryu­JIT) for x64, x86, ARM and ARM64 (re­placed JIT32 with .NET Core 2 and JIT64 with .NET Frame­work 4.6),

• AOT com­pi­la­tion for win-x86, win-x64, win-arm, osx-x64, linux-x64, linux-arm

and this is what we don’t have:

• BCL im­ple­men­ta­tion for iOS, iPadOS, tvOS and An­droid,

• AOT com­pi­la­tion for ARM64 (which would re­place .NET Na­tive toolchain in UWP and Mono’s AOT – win-arm64, ios-arm64, osx-arm64, etc.),

• Xcode in­te­gra­tion run­n­ing on Ap­ple Sil­i­con.

Ob­vi­ously, the bot­tle­neck is not the run­time, but dif­fer­ent ports of BCL. His­tor­i­cally, .NET Frame­work has its own, Mono has its own and UWP has its own. What started as Portable Class Li­braries, con­tin­ued to .NET Stan­dard and led to .NET 5. I be­lieve Xa­marin and .NET 5 will merge in .NET 6 mile­stone. Although it was meant to be done this year, we just must wait an­other year.

C# 9

When you tar­get .NET 5, you can use C# 9. Here are some of fea­tures you can adopt.

Records

Record is a new type. It is like a class, but it can in­herit only from an­other record and all its mem­bers are read-only. Un­like structs, record is still ref­er­ence type.

Nullability

Nul­lable ref­er­ence types was fea­ture of C# 8. Noth­ing new here, ex­cept that whole BCL is now an­no­tated for nul­la­bil­ity.

Covariant returns

In­her­ited class which over­rides a prop­erty can re­turn more spe­cific type. It is very use­ful. Who knows why we must wait so long?

The future is bright

The first .NET 6 Al­pha SDK which sup­ports ma­cOS ARM64 was re­leased 2 days ago. In fact, Ap­ple Sil­i­con is al­ready sup­ported.

The most im­portant as­pect of .NET 5 is that ev­ery new ver­sion of .NET can now af­ford to in­tro­duce break­ing charges. It will boost its de­vel­op­ment. The prob­lem with pre­vi­ous ap­proach was that a sys­tem-wide .NET Frame­work up­date af­fected all ap­pli­ca­tions thus this up­date had to be 100% back­ward com­pat­i­ble. It is no longer nec­es­sary. Ev­ery ap­pli­ca­tion can now carry its own run­time. Sweet. You have a choice.

• Pub­lish a portable bi­nary. It re­quires a run­time, or it can be com­piled to na­tive code.

• De­ploy the app and its run­time. Mul­ti­ple run­time ver­sions can be in­stalled side by side.

• Com­pile the app with all de­pen­dent li­braries to na­tive code. It will tar­get a sin­gle OS ven­dor and a sin­gle in­struc­tion set.

What's bet­ter for who de­pends on what you do. Li­brary makers will ap­pre­ci­ate the first choice. Web de­vel­op­ers will prob­a­bly use the sec­ond. Desk­top, mo­bile and IoT ap­pli­ca­tion cre­ators will ben­e­fit from the third.

Kaizen – 改善

Mi­crosoft is the best com­pany in the en­tire world… in mak­ing things again, again and over again un­til the world ends. What we thought would be .NET 1 will even­tu­ally be .NET 6. Imag­ine where .NET would be to­day if all the in­vest­ments into Mono, Sil­verlight, Moon­light, .NET Mi­cro Frame­work, XNA, DNX, Ex­pres­sion, WP, Xa­marin, WinRT and .NET Core would orig­i­nally con­tribute to one strong frame­work in­stead of its frag­men­ta­tion.

.NET 5 is the first step in uni­fy­ing ev­ery­thing around .NET ecosys­tem into one foun­da­tion which will be slowly but surely mov­ing for­ward. From a sin­gle per­for­mance im­prove­ment in .NET run­time will ben­e­fit UWP app, IoT de­vice, ASP.NET web page or iOS app. (Un­for­tu­nately, the same ap­plies to bugs too.) All de­vel­op­ers tar­get­ing these plat­forms can take ad­van­tage of Roslyn im­prove­ments. And fi­nally, it would be pos­si­ble to grab a NuGet pack­age no mat­ter which port of BCL you are cur­rently us­ing. When I in­stalled NuGet pack­ages, I saw va­ri­ety of de­pen­dent pack­ages for all pos­si­ble pro­files. Since this fall, the lat­est ver­sions of them has no de­pen­den­cies and tar­gets only .NET 5. From a li­brary de­vel­oper's per­spec­tive, .NET 5 is just an­other ver­sion of .NET Stan­dard. That’s the world I want to live in.

When all .NET ecosys­tem uni­fies, it will be un­re­al­is­tic to make it ob­so­lete and it build up from the scratch again. The only pos­si­ble way would be slow con­tin­ual im­prove­ments in per­for­mance, pro­ces­sor ar­chi­tec­ture sup­port and SDK/toolkit/OS tar­get­ing.

And by the way, since whole .NET de­pends heav­ily on just in time com­piler, it would be use­ful to re­mind that in in­dus­try this idea was in­tro­duced by Ki­ichiro Toy­oda. It's no ac­ci­dent that one part of the fa­mous Toy­ota Pro­duc­tion Sys­tem is the Kaizen prin­ci­ple.