Forem: Gokul

How .NET Really Works: From Build to CLR Execution Explained Simply

Gokul — Sun, 22 Jun 2025 16:04:30 +0000

I used to wonder why we use a “slow and bloated” framework when languages like C produce tiny binaries and run so efficiently. I never really knew what happened under the hood of every .NET app I created, and each new release hides even more details behind abstraction.

I promised myself that, to love my job, I must first appreciate the tech I work with. This article is my attempt to understand how .NET and its runtime work. Hope you enjoy it! 😊

We all know C# is a compiled language so there is are 2 phases in it Build Phase and Run Phase

Let’s start with what happens during the build phase.

Calm before the storm - the so-called Build phase 🤣

Internally, MSBuild is invoked when we enter dotnet build in CMD:

SDK selection MSBuild checks the SDK specified in myapp.csproj, for example:

   <Project Sdk="Microsoft.NET.Sdk.Web" />
   <!-- or -->
   <Project Sdk="Microsoft.NET.Sdk" />

SDKs live under:

   C:\Program Files\dotnet\sdk\<version>\Sdks

Load .props files

These set environment variables, global properties, and defaults (output path, configuration, etc.).
Gathers all project items which includes
- *.cs source files
- Referenced assemblies (e.g., System.Net.Http.dll) these are the using libraries which use in our c# code, each using statement corresponds to a .dll file which is placed in C:\Program Files\dotnet\shared\Microsoft.NETCore.App\6.0.36
- NuGet packages (e.g., StackExchange.Redis)
Load .targets files

These define what actual build steps to run. these can include predefined sequece of steps like
1. Restore
2. PrepareResources
3. Compile
4. GenerateAssemblyInfo
5. CopyFilesToOutputDirectory
6. Build
During above sequence we have Compile step

During compile step MSBUILD will use roslyn compiler to compile .cs file into IL ( .dll files)
- compiler will enforce CLS rules
- compiler also maps all language specific types to CTS-defined types ( e.g., int -> System.Int32 )
- Both CLS ( Common language specification ) and CTS ( Common Type System ) plays vital role in produced IL( Intermediate Language ) code.
Output

MSBuild drops the generated .dll, optional .exe, *.pdb, *.deps.json, etc. into:

.\bin\Debug\net8.0\

The Actual strom - The Run Phase 🍃

dotnet run

Does two things:

dotnet build ( will be skipped if already done and no changes are detected )
dotnet myapp.dll ( actual execution of your application starts here )

Note:

So far, we have compiled our code into .dll and .exe files along with other dependencies.

These files are also called IL (Intermediate Language) code.
They cannot be directly executed on Windows, Linux, or any OS.

Why?

Because they are not machine code.

You may ask:

What is the purpose of this extra step? Why not directly convert the source code into machine code?

There are several reasons why this was implemented:

Cross-platform: IL runs anywhere the CLR exists.
Runtime optimisation: JIT tailors code to the actual CPU.
Security & verification: CLR checks IL for type safety and memory violations.
Language interoperability: C#, F#, VB.NET, etc., all compile to the same IL.

Enable verbose host tracing

Before we proceed further its better if we enable below flag for detailed CMD traces.

set COREHOST_TRACE=1

Execution starts when dotnet myapp.dll is called :

As part of execution below command is executed internally.

dotnet exec --additionalprobingpath C:\Users\YourName\.nuget\packages C:\Users\YourName\Desktop\myapp\bin\Debug\net8.0\myapp.dll

so what it does ?

It kicks of an Execution Sequence called CoreHost chain :

dotnet.exe ( located in "C:\Program Files\dotnet\dotnet.exe" ) is called.
- This acts as the entry point of CoreHost chain.
- From here directly calls hostfxr.dll file
Hostfxr.dll is called!
- resolved runtime sdk
- Uses --additionalprobingpath to locate NuGet packages
- Chooses appropriate framework
hostpolicy.dll is called :
- loads dependecy based on .deps.json file (found along with myapp.dll bost build ).
- Resolves and loads all runtime + app assemblies. basically loads below things
  - our app dll (myapp.dll)
  - Reference library if any ( Newtonsoft.Json.dll )
  - .Net runtime assemblies like ( System.Console.dll )
  - Other Dependency files mentioned in *.deps.json file.
- Finally once all these are done, coreclr.dll is called.
coreclr.dll :
- The fricking start of the clr itself.

lets talk about what clr is and why it is important.

As discussed before, the CLR (Common Language Runtime) acts as a runtime platform or container environment capable of processing and executing IL code. It also provides several essential runtime services:

Memory management via Garbage Collection
Conversion of IL to machine code using the JIT compiler, which optimizes based on the runtime machine
Type safety verification through the CTS (Common Type System)

Once all these steps are completed the app will be up and running 🥳.

C# Inheritance: Virtual, Override, New, and Hidden Dangers

Gokul — Mon, 12 May 2025 11:39:34 +0000

C# inheritance is quite easy to implement but sometimes complex to understand.

Sure, most developers know what virtual, override, and new do. But what if we throw in a couple of casts and a few extra levels of inheritance? Now things aren’t so straightforward.

This article assumes you already know what inheritance is.

Initial Setup:

internal class Animal
{
    public virtual void sound()
    {
        Console.WriteLine("Animal makes noise");
    }

    public virtual void move()
    {
        Console.WriteLine("Animal moved");
    }
}

internal class Dog : Animal
{
    public override void sound()
    {
        Console.WriteLine("Dog barks");
    }

    public virtual new void move()
    {
        Console.WriteLine("Dog runs");
    }
}

internal class SuperDog : Dog
{
    public override void sound()
    {
        Console.WriteLine("Super Dog howls");
    }

    public override void move()
    {
        Console.WriteLine("Super Dog sprints");
    }
}

internal class Duck : Animal
{
    public new void sound()
    {
        Console.WriteLine("Duck quacks");
    }

    public override void move()
    {
        Console.WriteLine("Duck Duck go!");
    }
}

❓ Question 1: What is the output?

Animal al = new Animal();
al.sound(); 
al.move();  

Animal d1 = new Dog();
d1.sound(); 
d1.move();  

Animal d2 = new SuperDog();
d2.sound(); 
d2.move();  

Dog sd = new SuperDog();
sd.sound(); 
sd.move(); 

Animal dk = new Duck();
dk.sound(); 
dk.move();

❓ Question 2: What does virtual new mean?

Does it still hide the base implementation?
Does it still declare the method for further override?

❓ Question 3: Guess the output!

Update the Dog class like this:

internal class Dog : Animal
{
    public override void sound()
    {
        base.sound();
        Console.WriteLine("Dog barks");
    }

    public virtual new void move()
    {
        base.move();
        Console.WriteLine("Dog runs");
    }
}

Now what do you think this will print?

Dog d3 = new Dog();
d3.sound(); 
d3.move();

Constructors and Virtual Methods

Constructors are meant to initialize the class state before it can be used.

public class Base
{
    public Base()
    {
        Console.WriteLine("Base constructor");
        Init(); 
    }

    public virtual void Init()
    {
        Console.WriteLine("Init Called: Base class");
        // Base logic (maybe logging or setup)
    }
}

public class Derived : Base
{
    private List<string> _logMessages;
    private string _message = "Initialization starts";

    public Derived()
    {
        _logMessages = new List<string>(); 
    }

    public override void Init()
    {
        Console.WriteLine(_message);
        _logMessages.Add("Init Called: Derived class"); 
    }
}

❓ Question 4: Answer the following:

Does the above code run properly?
What does the output look like?

✅ Solutions:

Question 1:

Animal al = new Animal();
al.sound(); // Animal makes noise
al.move();  // Animal moved

Animal d1 = new Dog();
d1.sound(); // Dog barks
d1.move();  // Animal moved

Animal d2 = new SuperDog();
d2.sound(); // Super Dog howls
d2.move();  // Animal moved

Dog sd = new SuperDog();
sd.sound(); // Super Dog howls
sd.move();  // Super Dog sprints

Animal dk = new Duck();
dk.sound(); // Animal makes noise
dk.move();  // Duck Duck go!

Question 2:

virtual new declares a method that:

Hides the current base class implementation, and
Allows the method to be overridden in future derived classes.

So yes, it hides the base method for the current class and opens it for further overriding.

Question 3:

If a method exists in the base class and is accessible (not private), base.MethodName() will work inside the derived class—whether it's overridden or hidden using new.

Output:

Animal makes noise
Dog barks
Animal moved
Dog runs

Question 4:

Does the above code run normally?

Hell no!

Why?

Assume we create an object like this:

Derived dd = new Derived();

What really happens:

CLR starts memory allocation for the object.
Field _message is declared and initialized.
Field _logMessages is declared, but not yet initialized.
The base class constructor is invoked (derived constructor hasn't run yet).
Inside the base constructor, Init() is called.
Because it's virtual, it dispatches to Derived.Init().
In Derived.Init(), _logMessages.Add(...) is called—but _logMessages is null!
💥 NullReferenceException

Output before crash:

Base constructor
Initialization starts
Unhandled Exception: System.NullReferenceException

💬 Final Thought:

While this scenario may not be common in enterprise apps, it can easily slip in unnoticed—especially when refactoring or extending base functionality. Most exceptions are just mistakes we didn't anticipate.

If you like this article please leave a comment, i am new to blogging but love programming, i am trying to expand my circle and would now to interact with others, Thanks