It is the start of a new era of making software in the Microsoft ecosystem. This restart pushes .NET to where it was originally intended to be. Its purpose is simple – reaching every platform and every operating system with the C# language from Visual Studio. So why did it take so long? Well, this goal is anything but simple. Only the C++ language has been able to do that. .NET is an evolution of the C++ and COM world. Today, .NET finally supports native compilation.
Prior .NET era: C++ & COM
The C++ world has several disadvantages. There is no built-in memory management, no common type system, and MFC is not multiplatform. No library is portable to a different processor architecture than the one it was compiled for.
.NET Framework era: JIT & GC
The .NET Framework was intended to fix the disadvantages of the C++ and 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. The garbage collector makes programming dramatically easier. And finally, the task-based asynchronous programming pattern creates a thread abstraction layer, so wasting threads is no longer necessary (and battery drain does not occur).
Some would say that the .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, and 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 the .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 sued for software patent 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 .NET Framework profiles. (The first attempt – Portable Class Libraries – has never actually solved this problem.)
.NET Core era: native & multiplatform
.NET Core is the 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 portability in the context of .NET means:
- The 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 for which .NET Core (runtime) is implemented.
- A native application is a single executable. It does not depend on any runtime. It means that you do not have to check for the existence of .NET Core (runtime) on the target machine. The tradeoff is portability to other platforms.
- An assembly can reference another assembly originally written in another .NET language. It means that a 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
Visual Studio is an IDE available 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 extend Visual Studio with project templates, libraries, and tools.
.NET Standard
The bytecode – CIL – is standardized in the ECMA 355 standard. Similarly, libraries – BCL – are standardized in the 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 the methods that HttpClient has. The documentation describes its proper behavior.
Web Development
Classical ASP.NET web applications run on IIS (a web server), which is a component of Windows Server. Microsoft did not support running ASP.NET apps on operating systems other than Windows. That has changed. Dependency on IIS was replaced by the Kestrel web server.
Kestrel is part of ASP.NET Core. ASP is (in the 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 are challenging to fit with performance networking. Kestrel runs everywhere .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.
Windows Development
The traditional .NET Framework will still be 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 the case of native compilation) or by the system administrator by updating the .NET Core package (in the 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.
Future Development
The first patch (1.0.1) is scheduled to 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 for 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.