.NET Core vs .NET Framework Code Execution Process

Back to: ASP.NET Core Tutorials For Beginners and Professionals

.NET Core vs. .NET Framework Code Execution Process

In this article, I will discuss the .NET Core vs. .NET Framework Code Execution Process. So, we will understand the NET Core Application Execution Process by comparing it with the .NET Framework Application Execution Process and try to understand what changes have been made in the .NET Core.

.NET Framework Code Execution Process:

Let us first discuss the .NET Framework Application Execution Process. The code execution process of .NET Framework Application includes the following 4 steps.

1. Choosing a Compiler
2. Compiling Source Code to MSIL
3. Compiling MSIL to Native Code
4. Running Native Code

For a better understanding, please have a look at the following diagram.

Choosing a Compiler:

The .NET Framework allows us to develop applications using multiple programming languages, and each programming language has its own compiler. Depending on the language we choose, the respective language compiler will compile the source code:

• For C#, the compiler is CSC (csc.exe).
• For Visual Basic (VB), the compiler is VBC (vbc.exe).
• For F#, the compiler is FSC (fsc.exe).

In simple terms, when we write code in a particular language (C#, VB, or F#), the corresponding compiler is responsible for converting source code into a common format called Intermediate Language (IL) or Microsoft Intermediate Language (MSIL) that the .NET Framework can process.

Compiling Source Code to IL or MSIL Code:

Once you decide a programming language, then using that chosen programming language, you will write the code, which is nothing but your source code. Then, the respective language compiler will compile the source code into Intermediate Language (IL), also known as Microsoft Intermediate Language (MSIL). This IL or MSIL code is not tied to any specific hardware or operating system, i.e., platform-independent, meaning it can run on any system that has the .NET runtime. Along with IL, the compiler generates important information called Metadata, which describes the types and members used in your code.

• If you’re building a Console Application or Desktop Application, the IL code is saved in an .EXE file.
• If you’re building a Web Application or Class Library, the IL code is saved in a .DLL file.

In the .NET Framework, you can check the MSIL Code and Metadata using a tool called ILDASM. This IL or MSIL code is also called Managed Code because it is managed by the CLR (Common Language Runtime), which takes care of important tasks such as memory management and security.

Compiling IL or MSIL to Native Code:

When we run our .NET Framework application, the .NET runtime (CLR – Common Language Runtime) loads the compiled IL code from the .EXE or .DLL file. At this point, the Just-In-Time (JIT) Compiler within the CLR converts the IL or MSIL code into Native Code (also called Machine Code or Binary Code) specific to the underlying operating system and hardware.

This process of converting IL or MSIL Code to native code happens at runtime (just before the code is executed), allowing the JIT compiler to optimize the code based on the system it’s running on, ensuring that it can be executed efficiently by the operating system.

Running Code:

After the JIT Compiler converts IL code into Native Machine Code, the operating system can execute the code directly. During execution, the CLR provides the infrastructure needed to run the code, including services such as:

• Automatic Memory Management and Garbage Collection to handle memory allocation and deallocation.
• Security to protect the code from unauthorized access.
• Allows code to be debugged in different languages (like C#, VB, F#) seamlessly.

The combination of IL code and the CLR’s runtime services ensures that applications built with the .NET Framework can run efficiently on various platforms and devices.

Points to Remember:

In the .NET Framework, the Base Class Library (BCL), also known as the Framework Class Library (FCL), provides a rich set of built-in classes and functions that can be used to build .NET Framework applications.

• FCL includes classes for things like UI, data access, networking, file system, etc.
• BCL is a subset of FCL and provides classes for core features like collections, input/output, basic types, etc.

.NET Core Code Execution Process:

Now, let us see how .NET Core Code Execution takes place compared to the .NET Framework. The steps and process will be mostly the same. Only some of the components in .NET Core will be replaced compared to the .NET Framework. For a better understanding, please have a look at the following diagram.

Choosing a Compiler in .NET Core:

Similar to the .NET Framework, .NET Core allows us to develop applications using multiple programming languages like C#, F#, and Visual Basic (VB). Each programming language has its own compiler:

• For C#, the compiler used is part of Roslyn.
• For VB, the compiler is also part of Roslyn.
• For F#, the compiler is called F# Compiler (e.g., fsc.exe).

Depending on your chosen language, the appropriate language compiler will convert your source code into Intermediate Language (IL) or Microsoft Intermediate Language (MSIL), which can be processed further by .NET Core.

Compiling Source Code to IL or MSIL Code:

Once you write the source code in your chosen language (C#, F#, or VB), the language compiler (e.g., C# Compiler, VB Compiler, F# Compiler) compiles the source code into Intermediate Language (IL) or MSIL, which is platform-independent, meaning it can run on any system with the .NET Core runtime installed. Along with the IL code, metadata is generated. The .NET runtime uses this metadata for tasks like type checking, security, and garbage collection.

• If you build a console or desktop application, the IL code is saved in an .EXE file.
• For libraries or web applications, the IL code is saved in a .DLL file.

In .NET Core, this IL code is also called Managed Code because it is managed by the Core CLR (Common Language Runtime). The Core CLR is responsible for memory management, garbage collection, and ensuring security.

Compiling IL or MSIL to Native Code

When you run your .NET Core application, the .NET Core runtime (Core CLR) loads the IL/MSIL Code from the .DLL or .EXE file. The Core CLR is the execution engine in .NET Core and is responsible for executing managed code.

The Just-In-Time (JIT) Compiler (RyuJIT) in the Core CLR converts the IL/MSIL Code into Native Code (also called Machine Code or Binary Code). This conversion happens at runtime just before the code is executed, which allows the JIT Compiler to optimize the generated code based on the specific environment, hardware, and operating system it’s running on.

The process of converting IL to native code ensures that your .NET Core application can be optimized for the best possible performance on the specific machine it is running on.

Running Code:

After the JIT Compiler converts the IL code into Native Code, the operating system can execute it directly. During execution, the Core CLR provides necessary runtime services to the code:

• Automatic Memory Management and Garbage Collection to manage memory allocation and deallocation.
• Security Services to ensure that the code is protected from unauthorized access.
• The ability to debug code written in different languages, similar to the .NET Framework.

This process ensures that applications developed using .NET Core can run efficiently across different platforms, making it cross-platform and suitable for different operating systems (like Windows, Linux, and macOS).

Changes in .NET Core:

The execution process remains the same. Only a few components are changed compared with the .NET Framework.

Compilers in .NET Core:

In .NET Core, the compilers have been modernized, and many parts have been made open source.

• Roslyn: The Roslyn compiler is used for both C# and VB. Roslyn is a powerful and modern compiler that provides a compiler-as-a-service model, which means you can use it not only to compile code but also for tasks like code analysis, syntax highlighting, and real-time diagnostics in IDEs like Visual Studio.
• F# Compiler: For F#, the compiler is still maintained, but with F# 4.1, it has undergone changes to work seamlessly with .NET Core.

Note: The key difference here is that .NET Core uses the Roslyn compiler platform, which is faster, more extensible, and provides richer tooling support compared to the compilers used in the .NET Framework.

Class Libraries in .NET Core:

In .NET Core, we have a new set of libraries called CoreFX. CoreFX is a reimplementation of the Framework Class Libraries (FCL) or Base Class Libraries (BCL). It aims to be lightweight, modular, and cross-platform. The modular nature of CoreFX means you can add only the packages that your application needs, leading to smaller, more efficient applications.

The CoreFx library is portable and cross-platform, meaning it works seamlessly on Windows, macOS, and Linux, unlike the .NET Framework libraries specific to Windows.

CLR (Common Language Runtime) in .NET Core:

In .NET Core, we have a new runtime called CoreCLR. CoreCLR is a reimplementation of the CLR specifically designed to be lightweight, modular, and cross-platform. It works on Windows, Linux, and macOS, whereas the CLR in .NET Framework is Windows-only. The CoreCLR provides a similar set of services as the .NET Framework’s CLR, such as garbage collection, memory management, type safety, and threading.

RyuJIT is the new version of the JIT compiler used in CoreCLR. RyuJIT is designed to be faster, more efficient, and modernized compared to the traditional JIT compiler used in the .NET Framework. It compiles IL code into native code more optimally, considering newer hardware architectures and enabling performance improvements.

Now, the obvious question that should come to your mind is why we have the reimplementation of all these components that we already have in the .NET framework. So, the answer is the same as why Microsoft implemented .NET Core, i.e., for Open-Source and Cross Platform.

In the next article, I will discuss the Differences Between the .NET Core vs. the .NET Framework. In this article, I explain the .NET Core vs. .NET Framework Code Execution Process. I hope you enjoy this .NET Core vs. .NET Framework Code Execution Process article.