What is .NET Core? Released in 2001, the .NET framework made it easier for developers to create applications on the internet. However, the need for faster and more simple deployment (among others) drove the need to develop a more modular system. Its .NET Core, released in June 2016, is a modular and smaller implementation of .NET that is designed to be cross-platform and open source, and it’s optimized for cloud-specific workloads. In this post, we’ll look at the evolution of the .NET framework and family and the developments that have paved the way for .NET Core.
What is .NET Core? Birth of the .NET Framework
At the time, Microsoft was just starting the first browser war on the Windows desktop, Apple was waiting for the return of Steve Jobs and Linux, like the web, was just five years old. Microsoft was focused on a developer experience based mostly on Visual Basic 6.0, and was looking for the successor of COM technology. They also purchased a Java Virtual Machine from a little company called Colusa in order to have a technology that could keep up with Java’s promising features.
In 2001, Microsoft released the .NET Framework in version 1.0. It served as a framework for using multiple languages, from legacy Visual Basic to the new (at the time) C#, to develop on mainly two application models: desktop and web. These applications implemented the “drag & drop” development philosophy that was desirable at the time.
Since then, the .NET Framework has evolved and grown, and many new versions have been released. By 2012, it was time for something a little more innovative.
What is .NET Core? Meeting future requirements
Since the .NET Framework was released, a lot of things have happened in the IT world that have shaped the need for a new development framework.
- The Microsoft ecosystem. The Windows family of operating systems has it market share, most notably in the enterprise market. However, internet companies are born with Linux, and for the desktop, MacOS is adopted for its simplicity. Microsoft is a developer’s company and it wants to bring its tools to other platforms.
- Open Source. These days, requirements, experience, comparison, and inspiration all come from the community. The community of users and developers make an important contribution of feedback in terms of ideas and for code.
- Mono. The first open source implementation of the standard Common Language Infrastructure specifications – ECMA – and ISO has become a common framework for some important application models such as Unity and Xamarin.
- New Architecture. Intel x64 architecture dominates the cloud, server, and desktop market. With the advent of smartphones and tablets, ARM architecture has become dominant with millions of processors and devices sold. The Internet of Things event has increased the phenomenon by putting ARM processors on many connected devices, connecting billions of devices to the Internet.
- New deployment models. Twenty years ago, we were investing in statically and strongly typed, object-oriented languages to guarantee code and application quality. This is no longer valid, as applications have increased their complexity. Today, we talk about Application Lifecycle Management as a guarantee for code quality. Source Code Management, Continuous Integration, Continuous Delivery, Automated testing, Containerization, Docker, and Microservices are all first requirements when developing a solution. Therefore, we need a tool that can simplify this approach.
- Command Line. As its name implies, Windows has always been a graphical user interface for simplifying the approach to ordinary tasks that should be executed quickly and easily. Unix and Linux have always inspired the adoption of the command line as the most powerful and flexible way to handle DevOps tasks.
- Breaking changes. Microsoft is experienced in supporting retro-compatibility with legacy applications. However, legacy can prevent pushing performance and new functionalities to extremes. This is what we need today.
- Cloud. For us at Cloud Academy, the most inspiring scenario is the possibility of developing services to be executed in the cloud. The cloud brings all these topics together: Performance, portability, openness, architectures, languages, operations. For Microsoft, the cloud represents the center of its new strategy for being a cloud-first company.
A new member of the .NET Family
.NET Core means many things. .NET Full (and to be more precise, the current version that is .NET 2015, or 4.6.2) is Windows specific, and only a subset of it is portable. In this way, “core” emphasizes what is core and portable between the platforms.
“Core” needed to be different from .NET so that it could meet the needs of different platforms. There are some breaking changes that do not allow bringing code from .NET without modifications. And, there are possibilities that you can’t go back. And, we can’t bring a legacy Windows concept on Linux or Mac.
As a member of the .NET family, .NET Core can also embrace Mono, as Microsoft has acquired Xamarin. It is quite unlikely that Microsoft would move that code base from Mono to .NET.
What is .NET core and what does it mean to be part of the .NET family?
Being a .NET Framework means implementing:
- Common Language Runtime (CLR): Services common for all language implementers (Type System, language features like inheritance, generics, interfaces, and overloading for object-oriented programming). Also, Async Programming, Threading, Structured Exception Handling, Attributes, Garbage Collection, Delegates).
- Intermediate Language (IL): The generated code from each language compiler.
- Common Language Specifications (CLS): Rules for interoperability among languages.
- Base Class Library: A set of types (System.Object, System.Int32, System.String, System.IO.*, …) common to the .NET family.
- Framework: The implementation of all of these elements.
.NET Core is another .NET framework with other members like .NET 2015 and Mono with Xamarin (184.108.40.206).
So, what is .NET Core? It’s a modular and smaller implementation of .NET that is designed to be cross-platform and open source to meet the next 10 years of software development. It is optimized for cloud-specific workloads and implements these specific application models:
- Console applications (worker roles)
- NET Core (web roles)
There is also a Universal Windows Platform for store applications and devices. This scenario is still under development and we’ll see its potential in the near future.
One issue that .NET Core is trying to solve is libraries. The three mentioned stacks are three separate stacks, which creates several problems:
- The two new implementations are codebase fork.
- If a new implementation is needed, you would most likely need to reimplement them on each platform.
- With different ship cycles (e.g., Windows for .NET Framework) they will align at different times.
There are also issues for developers:
- Key APIs are not present on all platforms.
- Different implementations on each platform.
- Need to target a small common denominator to reuse code.
- Need to master 3 base class libraries.
To address these issues, Microsoft came up with a single library solution.
Starting from the current experience with Portable Class Libraries which are used to solve portability issues among Windows, Silverlight, and Windows Phone apps, the common functionalities have been selected and classified. It has been implemented in a set of reference assemblies that are binary compatible with all platforms. This means that they need to be implemented once for the defined standard. The standard can evolve over time and different platforms can implement different standards.
All reference libraries are downloadable as nugget packages, identified by a moniker that is an alias to the target platform and the version supported (ex. «netstandard1.6»). This mechanism can support either a standard scenario that is necessary for portability and vertical scenarios where we need to refer to a particular platform that has some specifically required functionalities. The referenced libraries are installed side by side into the application project so it can be compiled and packaged.
The application is complete, but it cannot be executed because the full implementation is missing.
In fact, the full implementation is inside the framework that is installed on the specific machine where the application is run. Every released framework adheres to some platform and standard. In case of “netstandard1.x”, every framework that implements it can run any application built with the platform independently from the Operating System.
Every supported platform is now listed and identified with a Runtime Identifier – RID. Inside the .NET Core project you can target specific platforms so that the build system can understand at compile time whether all functionalities are supported for the required platforms.
Breaking Changes and project migration
If you’re already a .NET developer, here is a list of major breaking changes that have been introduced. This is important to know if you’re evaluating costs for a possible migration:
- No AppDomains (Infrastructure exists but it is no longer usable in terms of API. There is a new AppContext object and AssemblyLoadContext to dynamically load assemblies.)
- No Remoting
- No Binary Serialization
- No Code Access Security (CAS)
- No Global Assembly Cache
- Anything Windows-specific (registry, ACLs, perf counters, etc.)
- All assemblies are deployed privately
- An assembly for each namespace (no more mscorelib.dll)
In .NET Core, the following application models are no longer supported:
To be continued…
In future posts, we will dive into more details (running the dotnet.exe CLI, introducing ASP.NET Core apps) to help you understand whether .NET Core is right for you.
For now, we can say that .NET Core has inherited all the good aspects that .NET has implemented in the last 20 years. And, it has been rewritten to be updated with all the modern challenges that the cloud now requires. You can implement applications in a mature, evolved, high-performance environment for statically typed, strongly typed languages like C#. With this language, we can target Windows and Linux for building cloud workloads, and we can develop on Windows, Linux, and Mac OS.