DEV Community: El cat bot

Understanding Constants in C#: CLR perspective

El cat bot — Sat, 12 Jul 2025 00:14:10 +0000

Introduction

Applications often require specific values that do not change at runtime. For example variables containing values such as number of months in a year, PI number, Euler number, etc. Since these values are referenced by different modules, it could be catastrophic if they're modified by threads or processes. The C# language helps to avoid this situations by including constants.

What is a Constant?

A constant is a value assigned at compile time and will never be modified at runtime, meaning it won't change for the whole application lifetime.

A constant must be declared using the const keyword and primitive types (int, bool, decimal, double, byte, char, string, etc.). Here's an example:

public class MyMathClass
{ 
    public const double Pi = 3.1416;
}

The correct way to call a constant value is by indicating its Type as follows:

string message = $"The PI number is { MyMathClass.PI }";

As mentioned above, a constant value is defined at compile-time. Therefore, the compiler will throw an error if any piece of code tries to modify it:

By using constants, values will be preserved for the whole application lifetime process.

There's a question to be answered, why are constant values called as static fields and not through objects?

Compile-time constant definition

Due to their immutable nature, the compiler saves constant's value in the assembly metadata. This makes them static members rather than instance members.

When code calls a constant, the compiler directly checks in the metadata and gets the constant's value to embed it into the IL (Intermediate Language) code. Let's see this by printing the PI constant using Console.WriteLine:

public class MyMathClass
{ 
    public const double PI = 3.1416;
} 

public void Main()
{
    Console.WriteLine(MyMathClass.PI);
}

IL Code:

IL_0000 nop 
IL_0001 ldc.r8  A7 E8 48 2E FF 21 09 40  // 3.1416
IL_000A call    Console.WriteLine (Double)
IL_000F nop 
IL_0010 ret

In IL_0001 ldc.r8, the compiler is just loading the value into the evaluation stack and then calls IL_000A call to print it. It will be imbedded everywhere it is called.

A comparison can be made by turning PI into a class field and calling it through a object instance:

public class MyMathClass
{ 
    public double PI = 3.1416;
} 

void Main()
{
    MyMathClass myClass = new();
    Console.WriteLine(myClass.PI);
}

Compilation generates a slightly different IL code:

// Main ()
IL_0000 nop 
IL_0001 newobj  MyMathClass..ctor
IL_0006 stloc.0    // myClass
IL_0007 ldloc.0    // myClass
IL_0008 ldfld   MyMathClass.PI
IL_000D call    Console.WriteLine (Double)
IL_0012 nop 
IL_0013 ret 

// MyMathClass..ctor
IL_0000 ldarg.0 
IL_0001 ldc.r8  A7 E8 48 2E FF 21 09 40  // 3.1416
IL_000A stfld   MyMathClass.PI
IL_000F ldarg.0 
IL_0010 call    Object..ctor
IL_0015 nop 
IL_0016 ret

In IL_0001 newobj of Main(), an instance of MyMathClass is being created. There, PI constant is assigned to 3.1416 (it calls MyMathClass..ctor).
IL_0006 stloc.0 and IL_0007 ldloc.0 store the object into a local variable and load the object into the evaluation stack.
Finally, in IL_0008 ldfld, PI value is loaded from the object and IL_000D call prints it.

Considerations

Again, C# constants are defined into IL code, meaning that there's no memory allocation for it at runtime. Knowing this, it's worth pointing out that because an address does not exist for constants, they cannot be passed by reference (ref keyword).

If a constant is modified (a different value) and the method calling the constant is in a different assembly (.dll), the application must be completely recompiled. Consider the following:

PI constant is defined within MyMathClass, which is also defined in Assembly 2.
The Main method is within Program class, which is contained in Assembly 1. This method calls and prints PI.
When both .dll compile together, Console.WriteLine(PI) in Main method is taking 3.1416 value in IL code.

But what would happen if PI is updated to 3.15?

If for some reason PI is now equal to 3.15 instead of 3.1416, Assembly 1 calling PI constant must be recompiled along with Assembly 2. That's because PI's value is updated at compile time and not at runtime. The following image explains the situation:

After Assembly 2 recompiles, PI constant is now 3.15, so a decision process is shown, asking if Assembly 1 has been recompiled. If recompiled along with Assembly 2, PI constant in Main method updates to 3.15, if not, PI remains 3.1416. It would be a disaster for future calculations because it has a different value in each part of the application.

Conclusion

The .NET CLR helps with immutability when a value needs to remain the same throughout application's lifetime. Constant values are good approach written in C# and then treated as a static member by the compiler.

It's worth mentioning that a constant value is imbedded intro every IL code call. Therefore, this value must be immutable.

If for some reason it needs to be modified, it's recommended to replace the constant for a read-only field. Read-only fields assign values at runtime, meaning that there is no need for full application recompilation.

What's next?

CLR via C# by Jeffrey Richter offers tons of information about type members.

Happy Learning =);

Understanding the .NET CLR: What Every C# Developer Should Know

El cat bot — Sat, 05 Jul 2025 17:44:43 +0000

Introduction

Every day of developer's career, interaction with a programming language is the way to compile and run applications. If no errors found, it just executes and performs its job.

Sometimes, new to intermediate developers have asked themselves at least one of the following questions:

What happens when code is compiled?
is CPU able to understand C# code?
How variables, objects are handled in memory?
What does "Run" mean?

Questions before are completely valid. To answer them, .NET has a powerful platform doing so much work behind the scenes: The CLR.

What is the CLR?

.NET CLR (Common Language Runtime) is the engine of the .NET environment where C# code is compiled and executed. Every application built on ASP.NET Core MVC, WinForms, MAUI, etc, needs a runtime to execute. It supports different programming languages such as C#, Visual Basic, F#, C++/CLI, among others. That's why the "Common Language" part of the name.

To put it simple, the CLR is a virtual machine that handles very important tasks:

C# code compilation into IL (Common Intermediate Language)
Code execution by JIT (Just-in-Time compiler)
Memory management by GC (Garbage Collector)
Exception handling
Thread management

It is worth mentioning that C# code is just text. A platform needs to bring C# code to life. That is CLR's job.

CLR code flow

All of those processes occur when a developer runs an application.

Taking into account the previous flow, now, questions at the beginning can be answered:

What happens when code is compiled?

After developers hit compile or execute "dotnet build" command, CLR transforms C# code into IL code and stores it in a .dll or .exe file. This file contains all IL code and metadata necessary for the JIT compiler to read. It is worth pointing out that IL is CPU independent, meaning it has to be translated later.

is CPU able to understand C# code?

No, CPU cannot read C# nor IL code. That leads us to think about how machine can read code. CLR is perfectly aware of this, which is why it has a specialized compiler called JIT (Just-in-Time). When application starts, JIT takes all the IL code from .dll files, performs optimizations and loads native machine code into memory. Now, CPU threads can execute instructions in code they can understand.

How variables, objects are handled in memory?

Once program code is running, information about objects and their values need an storage location. That's the job for:

The Stack
Garbage Collector (GC)

Value types (int, bool, decimal, etc ) and local variables in a method execution go directly to the Stack. The Stack is a LIFO (Last-in, First-out) storage. It allows two operations: adding data on the top (push) and returning data from the top (pop). This model is perfect for local variables to be disposed immediately after the method finishes. Think about a method doing Sum operation as the following:

public int Sum(int a, int b) => a + b;

As mention before, integers are value types and they are loaded to the Stack for fast execution. Therefore, the Sum of "a" and "b" is performed and the result is returned. Afterward, "a" and "b" are unloaded from the Stack:

For reference types (objects), the GC communicates to the OS to reserve memory and create a location where .NET objects will reside. This location is the GC Managed Heap. There, reference types and static objects are allocated. The managed heap is divided into segments called generations:

Generation 0 (G0)
Generation 1 (G1)
Generation 2 (G2)
Generation 3 or Large Object Heap (LOH)

Let's say there is an existing class called MyType. When creating an instance of MyType:

var myType = new MyType();

It goes directly to G0. The "new" keyword tells the compiler to add the necessary metadata to allocate this reference type, right on the Managed Heap.

It is worth noting that G0, G1 and G2 are also known as Small Object Heap (SOH). Together, GC and JIT allocate objects into SOH if object size is <= 85000 bytes. Otherwise, they go to the LOH.

When JIT needs to allocate a new object, it "asks" GC to retrieve a memory address, if there is no space on the managed heap, GC performs a Collection. It means, it releases memory by getting rid of unused objects.

What does "Run" mean?

When a dotnet application is executing previous CLR steps, it is running. That simple. On application startup, CLR performs IL compilation once, JIT compilation every time a method is called for the first time and memory management by allocating-collecting objects.

Conclusion

The CLR is a massive engine (almost invisible to developers) that powers all .NET Applications. It's important to start delving into CLR fundamentals to write better code. For example, when experiencing performance issues, it's better to understand how Garbage Collector works to detect memory leaks. Therefore, the problem could be a Managed Heap full of objects and likely in C# code level.

What's next?

Start reading about CLR implementation to understand this interesting but important topic. The following Microsoft documentation and books are packed with concepts to help digging deeper into CLR code and architecture:

The book of the Runtime: https://github.com/dotnet/runtime/blob/main/docs/design/coreclr/botr/README.md
Pro .NET Memory Management by Konrad Kokosa
The Garbage Collection Handbook by Richard Jones, Antony Hosking
CLR via C# by Jeffrey Richter
.NET IL Assembler by Serge Lidin

C# Delegates, the basics

El cat bot — Fri, 04 Jul 2025 00:14:43 +0000

In C#, we have a powerful feature that can help us reference methods for future execution. This implementation is the Delegate type.

Specifically, it defines methods, parameters and return type. Think about delegates as Callback method that it is passed into other methods.

Ordinary Method call.

Let's say We are writing a program that needs to make a discount calculation based on a client membership type:

Basic: 10%
Premium: 30%
No-membership: 0%

public decimal GetDiscount(decimal price, string customerType)
{
    if(customerType == "Basic")
    {
        return price = price * 0.90M;
    }
    else if(customerType == "Premium")
    {
        return price = price * 0.70M;
    }
    else
    {
        return price;
    }
}

var price = GetDiscount(450, "Premium");

Console.WriteLine(price); // 315.00

After passing a price of 450, discount will be 315. GetDiscount works but if we think about validations, this method shouldn't have to validate that the customer has a membership or not. In terms of Single Responsibility SOLID principle, GetDiscount should only have to calculate discount and return the value. That's all.

Delegate implementation

Fortunately, it is possible to add a delegate to clean up our code:

1. Declare the delegate:

public delegate decimal Calculation(decimal price);

It's worth pointing out that this delegate is a method wrapper. Delegate signature must match with our GetDiscount method. So, method return type and parameters must be equals to the delegate.

2. Modify GetDiscount to receive only Calculation delegate as a parameter:

public decimal GetDiscount(Calculation calculation, decimal price)
{
    return calculation(price);
}

Note our code is reduced to one line of code. That's because GetDiscount performs discount and method logic will be added as parameter when GetDiscount is called.

3. Call GetDiscount and pass our delegate and price as parameters:

GetDiscount(price => price * 0.90M, 450); // 405.00

GetDiscount(price => price * 0.70M, 450); // 315.00

When calling GetDiscount, the first parameter will be our discount delegate using anonymous function. Instead of writing discount process in GetDiscount, we pass it as parameter to be invoked later. The second parameter is price.

The Complete code:

public delegate decimal Calculation(decimal price);

public void Main()
{
    var discountBasic = GetDiscount(price => price * 0.90M, 450);
    var discountPremium =  GetDiscount(price => price * 0.70M, 450);

    Console.WriteLine("Having a price of 450: ");
    Console.WriteLine($"    Premium membership has a discount => {discountBasic}");
    Console.WriteLine($"    Basic membership has a discount  => {discountPremium}");
}

public decimal GetDiscount(Calculation calculation, decimal price)
{
    return calculation(price);
}

Multicast Delegate

There are situations where we have call more than one implementation, one after another, and each method shares signature (same return type, same parameters).

Let's say we have a program that creates an User and after that, it calls three methods to log a message to Local File, Azure and AWS cloud:

public void LogToAWS(string message)
{
    // Save to AWS Cloud....
    Console.WriteLine($"AWS => {message}");
}

public void LogToFile(string message)
{
    // File.Write....
    Console.WriteLine($"File => {message}");
}

public void LogToAzure(string message)
{
    // Save to Azure Cloud....
    Console.WriteLine($"Azure => {message}");
}

A CreateUser method calls each Log implementation:

public void CreateUser()
{
    // Create User logic...
    // User created
    var message = "User created Successfully";

    LogToAWS(message);
    LogToFile(message);
    LogToCloud(message);
}

// AWS => User created Successfully
// File => User created Successfully
// Azure => User created Successfully

That's perfectly working but what happens if new Log destinations are added. For example ElasticSearch and more. It wouldn't be clean adding more methods that do the same thing for different providers.

With Multicast delegates we can declare a class containing a delegate and a centralized method that invokes it. Let's see how it works:

1. Declare LogHandler delegate:

public delegate void LogHandler(string message);

2. Create MyLogger class:

public class MyLogger
{
    public LogHandler Log;

    public void LogMessage(string message)
    {
        Log?.Invoke(message);
    }
}

Here, we declare MyLogger class, a local delegate called LogHandler and LogMessage method. Our method accepts the message and then invokes our delegate with "Log?.Invoke()" syntax. See the method signature is still the same as all the previous Log methods.

3. Modify CreateUser method to call our delegate:

public void CreateUser()
{
    // Create User logic...
    // User created
    var message = "User created Successfully";

    var myLogger = new MyLogger();

    myLogger.Log +=  (message) => 
    { 
        // Send to AWS Cloud....
        Console.WriteLine($"AWS => {message}");
    };
}

Here, we created and instance of MyLogger class, this is where our delegate "Log" is located. After that, we assign our LogToAWS function using anonymous function. You may be asking "What happened with LogToAWS method?". We got rid of it. Why? Although is completely right to call it like this:

myLogger.Log += LogToAWS;

It's cleaner to assign an anonymous function for readability. But it's up to you how to call it.

Then we call LogMessage method and pass our message to invoke our function:

// Execute Delegate
myLogger.LogMessage(message); //AWS => User created Successfully

To add another function to the delegate, just assign it as a concatenation item:

myLogger.Log +=  (message) => 
{ 
    // File.Write....
    Console.WriteLine($"File => {message}");
};

The final code with all possible Loggers and MyLogger class:

public delegate void LogHandler(string message);

public class MyLogger
{
    public LogHandler Log;

    public void LogMessage(string message)
    {
        Log?.Invoke(message);
    }
}

public void CreateUser()
{
    // Create User logic...
    // User created
    var message = "User created Successfully";

    var myLogger = new MyLogger();

    myLogger.Log +=  (message) => 
    { 
        // Send to AWS Cloud....
        Console.WriteLine($"AWS => {message}");
    };

    myLogger.Log +=  (message) => 
    { 
        // File.Write....
        Console.WriteLine($"File => {message}");
    };

    myLogger.Log +=  (message) => 
    { 
        // Send to Azure Cloud....
        Console.WriteLine($"Azure => {message}");
    };

    myLogger.Log +=  (message) => 
    { 
        // Send to Elasticsearch....
        Console.WriteLine($"Elasticsearch => {message}");
    };

    // Execute Delegate
    myLogger.LogMessage(message);

    //AWS => User created Successfully
    //File => User created Successfully
    //Azure => User created Successfully
    //Elasticsearch => User created Successfully
}

I expect you got the idea and have learned the basics about delegates and more important, in which scenarios you can implement them.

So, Thanks for reading and keep learning =)