.NET Framework beta was released in early 2000s. After its launch, Microsoft realized the need to have a smaller/compact version of the framework to run on Smartphones/PDAs that used to run Windows Phone operating systems at that time. Hence they came up with .NET CF (Compact Framework). Since then, over a period of time, Microsoft has been refactoring the .NET Framework for various needs & purposes including web development (ASP.NET MVC), RIA (Silverlight), Windows Phone development, and the latest, Windows Store Apps.
This article is published from the DNC Magazine for Developers and Architects. Download this magazine from here [PDF] or Subscribe to this magazine for FREE and download all previous and current editions
At the same time, various features have also been added to the .NET Framework till its current avatar (as of this writing) - .NET Framework 4.6.2. So much has happened with the .NET Framework till date that it probably runs a risk of eventually following the famous anti-pattern – the big ball of mud. It was about time that the .NET Framework became leaner, reliable and modular to make it ready for future needs.
.NET Core 1.0, released on 27 June 2016, is a step towards that direction.
.NET Core Architecture - Key Considerations
Let us look at how and why is the .NET Core envisioned. Here are some key considerations for the thought process behind .NET Core:
Fragmentation
.NET Framework ended up having many flavors to cater to the changes in the application delivery platforms (desktop, web, mobile apps, RIA - Silverlight), as well as cater to the Windows ecosystem changes (Windows App Store, Universal Windows Platform). It all started with the .NET Compact Framework actually. The fragmentation resulted in separate silos of .NET Framework implementations over a period of time. There is no problem per se with this approach. However, in today’s world, when the overall technical architecture warrants to have apps supported on various devices, and of various kinds; it results into a nightmare for developers to code for various devices or app types (web, desktop or mobile). This was partially addressed earlier through portable class libraries (PCLs) and shared projects.
.NET core has now addressed this issue better, by having device specific implementations of runtimes.
The mscorblib conundrum
By design, quite a lot of features are bundled into mscorlib itself. This has advantages and disadvantages too. Given that now .NET Framework is envisioned to be lean and mean, and catering to various needs; a single installation per machine with an overload of various features does not become a scalable model going forward. So it would actually help to bundle only must-have features of .NET in order to make it lean and mean.
.NET Core will take care of this aspect more effectively now. .NET Core 1.0 (12 MB) is much smaller than the .NET Framework (200MB) and consists of smaller NuGet packages. The goal is to include components that your application really needs. For eg: with the .NET Framework, the Console class available in mscorlib was referenced by every .NET application, be it a Console, Web or a Windows application. However with .NET Core, if you want the Console functionality, you have to explicitly use the System.Console NuGet package. This keeps the framework lean and modular.
Framework Deployment
.NET Framework gets deployed as a single entity for every machine. This poses a problem when it comes to upgrading the Frameworks. While utmost care is taken by Microsoft to ensure backward compatibility without any regression, this approach causes an issue in terms of flexibility at design level (i.e. not being able to change behavior of interfaces etc).
This issue is handled well now by componentizing .NET Core. Since there are fewer dependencies, the deployment includes only those components that your application really needs.
Embracing the OSS world – truly
Microsoft has embraced the open source world more effectively of late, and the efforts are very well seen through various open source technologies becoming available on Azure, as well as Integrated Development Environments like Visual Studio and Visual Studio Code. In context of the .NET Framework, while Mono was available as an open source version of .NET Framework, both Mono and .NET Framework were not actually the “same” frameworks when it came to the source-code. Sure, the functionalities were similar; but the code base was a ported version.
With .NET Core, this is issue is being addressed appropriately. Since .NET Core and ASP.NET are now open source and platform-independent (supports Windows, Linux, and Mac systems); organizations that had earlier decided against running ASP.NET on their servers because it didn’t support Linux, are now looking at ASP.NET Core, as it can now run on Linux.
Performance
.NET Core can be built to native code using .NET Native, not only on Windows, but also on Mac and Linux systems. Since C# code is compiled to native CPU instructions ahead-of-time (AoT) using the CoreRT runtime, it leads to performance improvements especially when the program is booting, as well as reduces the memory footprint for applications.
So these were some of the key considerations that are being taken into account to envision .NET Core as a way forward to the future .NET Framework.
So what exactly is .NET Core?
.NET Core simply put is a subset and a modular implementation of .NET Framework that can be used for delivering .NET based applications for specific needs viz. web apps, touch-based mobile apps and so on.
Figure 1: .NET Core in NET Framework Ecosystem
Here are some salient points of this framework (relates to v1.0):
1) .NET Core is a forked-out version of the .NET Framework codebase, and it focuses on web and mobility based services initially. This is supposed to get extended further in upcoming versions of .NET Core. The probable additions would be Xamarin based mobile applications, UWP (Universal Windows Platform), Windows applications etc.
2) It can service web app development through ASP.NET 1.0 Core, and will also support mobile/touch based development via .NET Native.
3) This forms a common baseline for running .NET across multiple platforms (hence the mention of Mac & Linux in Figure 1).
4) It banks on the CLR implementation for .NET Framework for consistency and reliability of various offerings of .NET Framework. It also uses appropriate compiler infrastructure to ensure that the coverage of languages supported is ensured.
5) NuGet packages are a new addition to the mix. This is a fundamental shift towards making .NET more modular through a package driven approach, and it also depicts the overall thinking process followed by Microsoft of late of making .NET a community driven, open-source based Framework in the future. Since .NET Core is based on small NuGet packages, changes can be implemented more easily.
As it is evident from various features, .NET Core is certainly a step towards Microsoft’s journey to make .NET Framework a Standard subsequently.
.NET Core - what it is & what it is not?
Now that we have got an idea about the overall architecture of .NET, let us dive deeper to understand what .NET Core is, and what it is not. This is particularly important in order to understand how and why .NET Core has specific features, and also why it doesn’t have some of the .NET Framework features.
So, .NET Core is:
1) Open Source: Going with the newly adopted philosophy at Microsoft, it is a no brainier that .NET Core is open source. It is available on GitHub under standard GitHub MIT license.
2) Cross Platform: .NET Core has been recently launched to run on Red Hat Enterprise (more details here). This gives a clear indication of how serious Microsoft is about the cross-platform commitment when it comes to .NET Core. Currently .NET Core runs on Windows, MacOS and of course Linux. A detailed list of supported OSes can be found here.
3) Flexible: The design goal of .NET Core ensures that you can include it in your app as embedded runtime, or it can be used as a usual machine-wide framework too (like .NET Framework)
4) Compatibility: It is fully compatible with .NET Framework, Mono and Xamarin.
5) NuGet Support: Realizing the issues with tight-bundling of .NET Framework, Microsoft had already started using packaged class libraries, and NuGet was used as the vehicle to drive this effort. Microsoft plans to use the same vehicle going forward for .NET Core too.
6) API Coverage: While there are many APIs that are common between .NET Core and .NET Framework, a lot has been removed as well, especially those APIs that are tightly bound to Windows like WinForms and WPF. The beauty of this framework however lies in being able to bundle only those APIs that your application would need (of course, to certain extent).
7) Command-line: This is something new and interesting. .NET Core comes with a lot of command-line tools such as “donet.exe” and so on for performing various tasks. A detailed list of all commands can be found here.
And .NET Core is not:
1) It is NOT another or newer version of .NET Framework. Let us just be absolutely clear about it.
2) It does not come pre-bundled with UI development for WPF. You will need to use .NET Framework for that. So nothing much changes really for desktop based development.
3) .NET Core is not designed with the focus of being smaller than the .NET Framework. Rather the aim is to create a framework that uses only those components that the application needs.
.NET Framework vs. .NET Core
Since .NET Core is essentially a different way of looking at overall Framework architecture of .NET, it obviously comes with some preconditions or changes.
1) Reflection support is going to be different. It is generally looked upon as a very expensive feature to manage when it comes to code compilation, and the output of compiler. So it may happen that Reflection as a feature either may not get supported in .NET Core, or will have a toned-down version of it included in future versions, or may eventually become an optional component.
2) App Domains are not supported in .NET Core. This has been done to ensure that it is a leaner implementation.
3) Remoting was more of a requirement to handle the architectures that had remote object invocation requirements. It also suffered from issues like performance and tight-coupling to an extent. Use of Remoting has reduced recently, and most of the requirements are now handled through loose coupling using WCF etc. So Remoting is more or less a forgotten technology, and hence has not made it to .NET Core.
4) Serialization of objects, contracts, XML etc. would be supported. However binary serialization wouldn’t be a part of .NET Core.
5) Sandboxing is another feature that is not considered as a first class citizen of new .NET Core world at this point.
The .NET Portability Analyzer will come in handy to determine if an assembly is available or not, and recommend a workaround.
.NET Core Architecture
Now that we have a fair idea and background of what .NET Core is, let us spend some time on the architecture of .NET Core. Please note that since .NET Core is evolving, there could be some changes to this architecture in the future.
Figure 2: .NET Core Architecture
Image loosely based on the following source
There are some key aspects that you can decipher from the architecture. The runtimes shown in Figure 2 will be serving the following purposes:
1) CoreCLR is the runtime that is optimized for multi-platform and cloud base deployments. You will be using this when you are building applications on ASP.NET Core.
2) .NET Native (also referred as MRT – Managed Runtime – at times) is the CLR for Universal Apps and is optimized to run on any device and platform natively, which runs Windows. This will follow AOT (ahead of time) compilation instead of erstwhile JIT compilation, and will be targeted for specific platforms say Linux-64 bit and so on. This will ensure a better runtime performance.
Unified BCL (Base Class Library) consists of the basic/fundamental classes that are a part of .NET Core. This also is called as CoreFX. .NET Core follows the NuGet model for delivery of packages for BCL.
As per the design goals of .NET Core, BCL has various app models on top of it. Currently .NET Core has the Windows Store App model and ASP.NET Core App model enabling developers to build applications for targeting appropriate platforms.
A little bit more about ASP.NET Core
All along, we have been discussing about .NET Core. It would be unfair to not briefly mention about ASP.NET Core since both go hand-in-hand. .NET Core currently allows you to build Universal Store Apps and ASP.NET Core apps. ASP.NET Core is a complete rewrite of ASP.NET, and combines MVC and Web API into a unified platform running on the .NET Core.
Editorial Note: A good primer on ASP.NET Core can be found over here http://bitly.com/dnc-aspnet-core .
.NET Core & App Development
All this is fine, but what happens to the current set of apps that you’ve already built with the .NET Framework? Do they have to work with .NET Core? Will they work on .NET Core? Well, let’s find out.
ASP.NET Apps
Here are a few important points to remember while create ASP.NET apps:
1) .NET Core supports the ASP.NET MVC application architecture. However if your apps are Web Forms based, then probably you can give .NET Core a pass, since Web Forms is not a part of the .NET Core. Having said that, porting to .NET Core might be a good option if you plan to refactor your existing apps. Why? Probably the next point will explain this.
2) If you have built applications using ASP.NET MVC, then the sole reason for you to port them to .NET Core is the cross-platform compatibility that .NET Core brings to the table. If this specific aspect is not important to you, or is not a part of your overall product map, then you are just fine with your current .NET Framework based set up.
3) ASP.NET Core is decoupled from the web server. While it supports IIS and IIS Express, for self-hosting scenarios, it comes with a brand new high performance, cross-platform Web Server called Kestrel.
UWP Apps
If you have built Universal Windows Apps (UWP) on Windows 8 or Windows Phone 8.1, then they are already built on .NET Core. This also covers various form factors that Windows runs on viz. tablets, phones and so on.
Desktop Apps
.NET Core is still not ready for desktop apps yet. For the time being, we have to wait and watch.
Silverlight
Well if you have Silverlight apps, then probably you will eventually need to move them to HTML5 based apps, if you haven’t already. A wise decision would be to look at .NET Core during this migration process, as one key design/architectural consideration in context of the app would be if it has to run cross platform.
Console Apps
You may have built some console apps on .NET Framework. They are the right candidates to be ported to .NET Core in order to support multiple OSes.
Should I take the plunge?
Oh yes, of course. With all the exciting features, ecosystem etc., you should certainly consider .NET Core. V1 of .NET Core is now available along with ASP.NET Core 1.0 and Entity Framework 1.0. You will need VS 2015 Update 3 and later, in order to build applications that use .NET Core 1.0.
Conclusion:
While the .NET Framework was designed to be cross-platform, practically it was always a Windows-only platform. .NET Core is a truly cross-platform framework. With the numerous versions of .NET Framework released so far, it is quite evident that Microsoft has been thinking through the overall design and architecture of .NET Framework from future-readiness perspective, and has been continuously improving the framework to stay up-to-date with different form-factors, ease of use, and rapid development of applications across platforms. While we are not there yet, .NET Core certainly seems to be an effort to make it the .NET Framework of Future.
The future indeed looks bright with .NET Core! Happy coding!
This article has been editorially reviewed by Suprotim Agarwal.
C# and .NET have been around for a very long time, but their constant growth means there’s always more to learn.
We at DotNetCurry are very excited to announce The Absolutely Awesome Book on C# and .NET. This is a 500 pages concise technical eBook available in PDF, ePub (iPad), and Mobi (Kindle).
Organized around concepts, this Book aims to provide a concise, yet solid foundation in C# and .NET, covering C# 6.0, C# 7.0 and .NET Core, with chapters on the latest .NET Core 3.0, .NET Standard and C# 8.0 (final release) too. Use these concepts to deepen your existing knowledge of C# and .NET, to have a solid grasp of the latest in C# and .NET OR to crack your next .NET Interview.
Click here to Explore the Table of Contents or Download Sample Chapters!
Was this article worth reading? Share it with fellow developers too. Thanks!
Rahul Sahasrabuddhe has been working on Microsoft Technologies since two decades and leads Microsoft Technology Practice at a leading software company in Pune. He has been instrumental in setting up competencies around Azure, SharePoint and various other Microsoft Technologies. Being an avid reader, he likes to keep himself abreast with cutting edge technology changes & advances.