It is the start of a new era of making software in the Microsoft ecosystem. This restart pushes the .NET where it was originally intended to be. Its purpose is simple – reaching every platform and every operating system with C# language from Visual Studio. So why did it take so long? Well, this goal is everything but simple. Only C++ language has been able to do that. The .NET is evolution of C++ & COM world. Today .NET finally supports native compilation.
Prior .NET era: C++ & COM
C++ world has several disadvantages. There is no memory management, no common type system and MFC is not multiplatform. None library is portable to other processor architecture than it was compiled to.
.NET Framework era: JIT & GC
The .NET Framework was intended to fix disadvantages of C++ & COM world. It was originally named COM 2.0. It has been very successful in doing that. Just-in-time compilation provides portability of libraries among multiple processor architectures. Garbage collector makes programming dramatically easier. And finally task-based asynchronous programming pattern creates a thread abstraction layer, so waste of threads is no longer necessary (and battery drain does not take a place).
Someone would say that .NET Framework was not multiplatform. It actually was – SSCLI (for Windows, OS X and FreeBSD systems), DotGNU (for Linux, Windows, Solaris, BSD and OS X systems and for x86, s390, SPARC, HPPA, StrongARM a PowerPC architectures) and Mono (for Android, Linux, BSD, OS X, Windows and Solaris systems and x86, x64, s390, SPARC, PowerPC, MIPS, ARM and IA-64 architectures). Only one thing was wrong – Windows SDKs were embedded into .NET Framework. It was very hard to port Windows rendering models (GDI+ and DirectX) or web server API (ISAPI) to other operating systems. Moreover, Microsoft did not help but rather suited for software patents violations.
The .NET Framework supports many platforms (microcontrollers, smartphones, PCs or servers), therefore there is no longer a single .NET Framework. Since different profiles have existed it has not been possible to create a single library that could be referenced by all of .NET Framework profiles. (The first attempt – Portable Class Libraries – has never actually solved this problem.)
.NET Core era: native & multiplatform
.NET Core is full .NET Framework without Windows SDKs plus some great features. What does it offer?
- common type system
- common exception handling
- common packaging system
- memory management
- compilation to bytecode (with dependency on runtime)
- compilation to native code (without portability)
Let’s clarify what the portability in context of .NET means:
- Just-in-time compiler (JIT) can execute any bytecode assembly. It means that targeting Any CPU makes the assembly executable on any operating system or processor architecture which .NET Core (runtime) is implemented for.
- A native application is a single executable. It does not depend on any runtime. It means that you do not have to check for existence of .NET Core (runtime) on target machine. The tradeoff is portability to other platforms.
- An assembly can reference another assembly originally written in another .NET language. It means that C# application can reference a library written in F# and vice versa.
Which great features was I mentioning?
- compiler as a service (Roslyn)
- embedded web server for ASP.NET Core apps (Kestrel)
- open-source software development (via GitHub)
- support by Microsoft and Red Hat
Visual Studio is an IDE at no cost for all users. There are two major versions – Visual Studio (for Windows) and Visual Studio Code (for Linux, macOS, and Windows). While Visual Studio is a very complex tool with its own source control, bug tracking and project planning system, Visual Studio Code is much more lightweight. It is a text editor with syntax highlighting, IntelliSense, debugging and Git version control. All SDKs by Microsoft are extending Visual Studio by project templates, libraries and tools.
The bytecode – CIL – is standardized in ECMA 355 standard. Similarly, libraries – BCL – are standardized in CoreFX set of APIs. For example, the networking stack is common to many devices and platforms, but all operating systems have different networking syscalls. The HttpClient class provides a necessary abstraction. The .NET Standard defines methods that HttpClient has. The documentation describes its proper behavior.
Classical ASP.NET web application runs on IIS (a web server) which is a component of Windows Server. Microsoft did not support running ASP.NET apps on other operating systems than Windows. That has been changed. Dependency on IIS was replaced by Kestrel web server.
Kestrel is part of ASP.NET Core. ASP is (in context of .NET Core) a web SDK. It is written in .NET Core and is optimized for high performance, because garbage collection and string immutability is something what hardly fits with performance networking. Kestrel runs everywhere where .NET Core (runtime) runs (Windows, Windows Server, macOS, RHEL, Ubuntu, Debian, Fedora, CentOS and openSUSE). Nowadays only bytecode compilation is supported. Native compilation will be supported later.
The traditional .NET Framework will be still supported. It also implements .NET Standard, so you can easily create a library targeting both .NET Framework and .NET Core. While .NET Framework is updated via Windows Update, .NET Core is updated with the app (in case of native compilation) or by system administrator by updating the .NET Core package (in case of bytecode compilation).
At this time, there are no SDKs for .NET Core to target Windows desktop, because these SDKs are part of the .NET Framework (Windows Forms and WPF). The SDK for Windows Store apps is called Universal Windows App Development Tools.
The first patch (1.0.1) is scheduled for arrive in August 2016. It will focus on performance improvements and bug fixes.
The first minor update (1.1.0) will change the build system from DNX to MSBuild, which is being ported to .NET Core. This update is scheduled to Q4 2016 / Q1 2017.
The first major update (2.0) could be released in the middle of 2017. It will unify all common APIs and classes across .NET Framework, UWP, Xamarin.iOS and Xamarin.Android into .NET Standard 2.0.