One of the most important duties of any runtime environment is memory management. Unlike lower-level languages like C or C++, developers do not manually allocate and free memory in languages like C#. Rather, the trash collector manages memory automatically. Few developers comprehend how the garbage collector actually determines what to collect, when to collect it, and why some objects survive longer than others, even though the majority of developers are aware that it cleans useless items.

The Microsoft.NET platform has a very advanced garbage collector. It doesn't eliminate items at random. Rather, it employs a collection of clever heuristics and algorithms intended to maximize memory and speed. Developers can create more effective and memory-efficient apps by comprehending how the garbage collector "thinks."

What Is the .NET Garbage Collector?
The garbage collector is a component of the Common Language Runtime responsible for automatic memory management.

Its main responsibilities include:

• Allocating memory for new objects
• Tracking which objects are still in use
• Reclaiming memory from unused objects
• Compacting memory to reduce fragmentation

Instead of forcing developers to manually manage memory, the garbage collector continuously monitors object usage and cleans up memory when necessary.

The Core Philosophy of the Garbage Collector
The .NET garbage collector is based on an important assumption known as the generational hypothesis.

The idea behind this hypothesis is simple:
Most objects die young.

In real-world applications, many objects are created for temporary tasks such as:

• Calculations
• Method calls
• Temporary data structures

These objects often become unused very quickly.

Instead of scanning the entire memory every time, the garbage collector organizes objects by age and focuses on cleaning younger objects more frequently.

The Generational Memory Model
The garbage collector divides managed memory into three main generations.

Generation 0 (Gen 0)
Generation 0 contains newly created objects.

Characteristics:

• Short-lived objects
• Frequent collections
• Very fast cleanup

When memory fills in Gen 0, the garbage collector runs a Gen 0 collection to remove objects that are no longer referenced.

Most objects are cleaned up at this stage.

Generation 1 (Gen 1)
Generation 1 acts as a buffer zone between short-lived and long-lived objects.

Objects move to Gen 1 when they survive a Gen 0 collection.

Characteristics:

• Medium lifetime
• Less frequent collections
• Acts as a filter for Gen 2

Generation 2 (Gen 2)
Generation 2 stores long-lived objects such as:

• application-level data
• caches
• static objects
• large data structures

Collections in Gen 2 are more expensive because the garbage collector must scan a larger portion of memory.
Because of this, Gen 2 collections occur less frequently.

How the Garbage Collector Decides to Run?
The garbage collector does not run continuously. Instead, it is triggered when certain conditions occur.

Some common triggers include:

1. Memory Allocation Threshold
When the runtime cannot allocate memory for a new object, the garbage collector starts a collection cycle.

2. System Memory Pressure
If the operating system reports low available memory, the garbage collector becomes more aggressive in reclaiming memory.

3. Explicit Requests
Developers can manually request a collection using:

GC.Collect();

However, forcing garbage collection is generally discouraged because it can reduce application performance.

How the Garbage Collector Finds Unused Objects?
The garbage collector uses a reachability analysis approach.
Instead of checking every object individually, it begins with a set of root references.

These roots include:

• Static variables
• Local variables on the stack
• CPU registers
• Active threads

From these roots, the garbage collector traces all reachable objects.
If an object cannot be reached from any root reference, it is considered garbage and becomes eligible for removal.
This process is called mark-and-sweep.

Memory Compaction
After removing unused objects, the garbage collector performs memory compaction.
This step moves remaining objects closer together to eliminate gaps in memory.

Benefits of compaction include:

• Reduced memory fragmentation
• Faster memory allocation
• Improved cache performance

Memory compaction ensures that future allocations can occur efficiently.

The Large Object Heap
Objects larger than approximately 85 KB are stored in a special area known as the Large Object Heap (LOH).

The LOH behaves differently from the standard generational heaps.

Characteristics of LOH:

• Used for large arrays and data structures
• Collected only during Gen 2 collections
• Historically not compacted frequently

Because of this, allocating many large objects repeatedly can lead to memory fragmentation.
Understanding how the LOH works helps developers design memory-efficient applications.

Background Garbage Collection
Modern versions of the .NET runtime support background garbage collection.
Instead of stopping the entire application while cleaning memory, the garbage collector performs many operations concurrently with application execution.
This reduces application pauses and improves responsiveness, particularly in server applications built with ASP.NET.

What Developers Should Learn From the GC
Understanding the garbage collector helps developers write better code.

Some key lessons include:
Avoid Creating Too Many Temporary Objects
Frequent object allocation increases pressure on Gen 0 collections.

Reuse Objects When Possible
Object pooling can reduce allocation overhead.

Be Careful With Large Objects
Large allocations can trigger expensive Gen 2 collections.

Avoid Unnecessary Object References
Keeping references alive longer than necessary prevents objects from being collected.

Common Misconceptions About Garbage Collection
Many developers misunderstand how the garbage collector works.

Misconception 1: Garbage Collection Runs Constantly
In reality, it runs only when necessary.

Misconception 2: Garbage Collection Always Improves Performance
While GC prevents memory leaks, excessive allocations can still harm performance.

Misconception 3: Developers Should Always Call GC.Collect()
Manual garbage collection is rarely beneficial and can disrupt the runtime’s optimization strategies.

Conclusion
The garbage collector in the Microsoft .NET ecosystem is not just a cleanup tool. It is an intelligent memory management system designed to optimize both performance and developer productivity. By organizing memory into generations, tracking object reachability, and reclaiming unused memory efficiently, the garbage collector ensures that applications written in C# can run reliably without manual memory management.

However, understanding how the garbage collector actually works allows developers to write more efficient code, reduce memory pressure, and build high-performance applications. In the end, the garbage collector is not magic it follows clear rules and strategies. The better developers understand those strategies, the better they can design applications that work with the runtime rather than against it.

HostForLIFE ASP.NET Core 10.0 Hosting

European Best, cheap and reliable ASP.NET Core 10.0 hosting with instant activation. HostForLIFE.eu is #1 Recommended Windows and ASP.NET hosting in European Continent. With 99.99% Uptime Guaranteed of Relibility, Stability and Performace. HostForLIFE.eu security team is constantly monitoring the entire network for unusual behaviour. We deliver hosting solution including Shared hosting, Cloud hosting, Reseller hosting, Dedicated Servers, and IT as Service for companies of all size.

Handling errors properly is one of the most important parts of building a robust ASP.NET Core Web API. If exceptions are not handled correctly, your application may crash, expose sensitive data, or provide a poor user experience. Global exception handling allows you to manage all errors in one place instead of writing try-catch blocks in every controller or service. This makes your code cleaner, easier to maintain, and more secure.

In this article, you will learn how to implement global exception handling in ASP.NET Core Web API step by step using simple language and real-world examples.

What is Global Exception Handling?
Global exception handling is a centralized way to catch and handle all runtime errors (exceptions) in your application.

Instead of writing this everywhere:
try
{
    // logic
}
catch(Exception ex)
{
    // handle error
}

You define a single place that handles all exceptions automatically.

Benefits:

• Cleaner code (no repetitive try-catch)
• Better error management
• Consistent API responses
• Improved security

Types of Exceptions in ASP.NET Core
Common types of exceptions you may encounter:

• System exceptions (NullReferenceException, DivideByZeroException)
• Custom exceptions (business logic errors)
• Validation errors
• Unauthorized access errors

Understanding these helps you handle them properly.

Approach 1: Using Built-in Exception Handling Middleware
ASP.NET Core provides a built-in middleware to handle global exceptions.

Step 1: Configure Exception Handling in Program.cs
var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/error");
}

This redirects all exceptions to a specific endpoint.

Step 2: Create Error Controller
using Microsoft.AspNetCore.Diagnostics;
using Microsoft.AspNetCore.Mvc;

[ApiController]
public class ErrorController : ControllerBase
{
    [Route("/error")]
    public IActionResult HandleError()
    {
        var context = HttpContext.Features.Get<IExceptionHandlerFeature>();
        var exception = context?.Error;

        return Problem(
            detail: exception?.Message,
            title: "An error occurred",
            statusCode: 500
        );
    }
}

This ensures a consistent response format.

Approach 2: Custom Middleware for Global Exception Handling
This is the most recommended and flexible approach.

Step 1: Create Custom Middleware

Create a new file: ExceptionMiddleware.cs
using System.Net;
using System.Text.Json;

public class ExceptionMiddleware
{
    private readonly RequestDelegate _next;
    private readonly ILogger<ExceptionMiddleware> _logger;

    public ExceptionMiddleware(RequestDelegate next, ILogger<ExceptionMiddleware> logger)
    {
        _next = next;
        _logger = logger;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        try
        {
            await _next(context);
        }
        catch (Exception ex)
        {
            _logger.LogError(ex, "Unhandled Exception");
            await HandleExceptionAsync(context, ex);
        }
    }

    private static Task HandleExceptionAsync(HttpContext context, Exception exception)
    {
        context.Response.ContentType = "application/json";
        context.Response.StatusCode = (int)HttpStatusCode.InternalServerError;

        var response = new
        {
            StatusCode = context.Response.StatusCode,
            Message = "Something went wrong",
            Detailed = exception.Message
        };

        return context.Response.WriteAsync(JsonSerializer.Serialize(response));
    }
}

Step 2: Register Middleware in Program.cs
app.UseMiddleware<ExceptionMiddleware>();

Place it early in the pipeline (before other middlewares).

Handling Different Exception Types
You can customize responses based on exception types.

Example:
private static Task HandleExceptionAsync(HttpContext context, Exception exception)
{
    HttpStatusCode status;
    string message;

    switch (exception)
    {
        case UnauthorizedAccessException:
            status = HttpStatusCode.Unauthorized;
            message = "Unauthorized access";
            break;

        case ArgumentException:
            status = HttpStatusCode.BadRequest;
            message = "Invalid request";
            break;

        default:
            status = HttpStatusCode.InternalServerError;
            message = "Server error";
            break;
    }

    context.Response.StatusCode = (int)status;

    var result = JsonSerializer.Serialize(new
    {
        StatusCode = context.Response.StatusCode,
        Message = message
    });

    return context.Response.WriteAsync(result);
}

Creating Custom Exceptions
Custom exceptions help represent business logic errors.
public class NotFoundException : Exception
{
    public NotFoundException(string message) : base(message) { }
}

Usage:
if (user == null)
{
    throw new NotFoundException("User not found");
}

Handle it in middleware for better responses.

Standard API Error Response Format
Use a consistent structure:
{
  "statusCode": 500,
  "message": "Error message",
  "details": "Optional details"
}

This improves frontend integration.

Logging Exceptions
Logging is critical for debugging and monitoring.

ASP.NET Core provides built-in logging:
_logger.LogError(exception, "Error occurred");

You can also integrate tools like:

• Serilog
• NLog
• Application Insights

Best Practices for Global Exception Handling

• Do not expose sensitive details in production
• Use structured logging
• Handle known exceptions separately
• Return proper HTTP status codes
• Keep response format consistent

Common Mistakes to Avoid

• Using try-catch everywhere
• Returning raw exception messages
• Not logging errors
• Incorrect status codes

Real-World Example Flow

• Client sends request
• API processes request
• Exception occurs
• Middleware catches exception
• Logs error
• Returns standardized JSON response

When to Use Global Exception Handling
Use it in:

• REST APIs
• Microservices
• Enterprise applications

It ensures reliability and maintainability.

Summary
Global exception handling in ASP.NET Core Web API helps you manage all errors in a centralized way. By using built-in middleware or creating custom middleware, you can ensure consistent error responses, better logging, and improved application security. This approach reduces code duplication and makes your application more professional and production-ready.

HostForLIFE ASP.NET Core 10.0 Hosting

European Best, cheap and reliable ASP.NET Core 10.0 hosting with instant activation. HostForLIFE.eu is #1 Recommended Windows and ASP.NET hosting in European Continent. With 99.99% Uptime Guaranteed of Relibility, Stability and Performace. HostForLIFE.eu security team is constantly monitoring the entire network for unusual behaviour. We deliver hosting solution including Shared hosting, Cloud hosting, Reseller hosting, Dedicated Servers, and IT as Service for companies of all size.

The "The conversion of a varchar data type to a datetime data type resulted in an out-of-range value" error is a frequent problem that developers run into while working with ASP.NET apps that communicate with SQL Server. We'll talk about the causes, short-term fixes, and long-term solutions.

Overview
Date and time values are frequently required when an ASP.NET application puts data into a SQL Server database. One frequent problem occurs when attempting to pass a DateTime value as a string, which SQL Server is unable to properly read because of regional variations in date formatting. When attempting to insert DateTime, this problem usually results in the "out-of-range" error.now entered into the database as a string.

The best solution 'parameterized queries' will be presented in this post after a thorough discussion of the issue and a walkthrough of a temporary patch. This method enhances the security and maintainability of your code in addition to fixing the mistake.

The Issue: Problems with DateTime Formatting
A particular format is required by SQL Server when data, particularly DateTime values, are put into a database. An out-of-range error may occur if SQL Server is unable to properly parse the DateTime value if it is supplied as a string in an unusual format.

Here is an illustration of a situation:
The code in an ASP.NET application may dynamically construct a SQL query to add information to the ContactInfo database, which contains a DateTime field:

str1 = "insert into ContactInfo(FirstName, LastName, MobileNo, Email, Country, State, City, APIType, AppName, Reason, ReasonComment, Message, CompanyName, ContactPerson, usertype, indCompanyName, date)";

str1 += " values('-', '-', '" + Contact1.Text + "', '" +
        Email.Text.Replace(" ", "") + "', '" +
        drpCountry.SelectedItem.Text + "', '" +
        state + "', '" +
        city + "', '" +
        Assestlist + "', '" +
        SiteName.Text.Replace("'", "_") + "', '" +
        drpApi.SelectedValue + "', '" +
        usercomment.Replace("'", "_") + "', '" +
        txtMessage.Text.Replace("'", "_") + "', '" +
        Fname.Text.Replace(" ", "") + "', '" +
        Lname.Text.Replace(" ", "") + "', '" +
        usertype + "', '" +
        infocompany.Text + "', '" +
        DateTime.Now + "')";

In this code, DateTime.Now is concatenated directly into the SQL query. When DateTime.Now is converted to a string, it might be formatted in a way that SQL Server cannot interpret correctly, such as:
13-01-2026 10:25:40

SQL Server may expect the DateTime to be in an ISO-compliant format like:
2026-01-13 10:25:40

If the format does not match, SQL Server may throw the out-of-range error.

Temporary Fix: Use ISO 8601 Format
The quickest way to fix this issue is to format the DateTime value as an ISO-compliant string before passing it to SQL Server. This ensures that SQL Server always understands the date format, regardless of the regional settings on the server.

Modify the code like this:
string sqlDate = DateTime.Now.ToString("yyyy-MM-dd HH:mm:ss");

str1 += " values('-', '-', '" + Contact1.Text + "', '" +
        Email.Text.Replace(" ", "") + "', '" +
        drpCountry.SelectedItem.Text + "', '" +
        state + "', '" +
        city + "', '" +
        Assestlist + "', '" +
        SiteName.Text.Replace("'", "_") + "', '" +
        drpApi.SelectedValue + "', '" +
        usercomment.Replace("'", "_") + "', '" +
        txtMessage.Text.Replace("'", "_") + "', '" +
        Fname.Text.Replace(" ", "") + "', '" +
        Lname.Text.Replace(" ", "") + "', '" +
        usertype + "', '" +
        infocompany.Text + "', '" +
        sqlDate + "')";

By using DateTime.Now.ToString("yyyy-MM-dd HH:mm:ss"), the date is formatted in a universally accepted ISO 8601 format, which SQL Server will always understand. While this works as a temporary fix, it’s not the most robust or maintainable solution.

The Long-Term Solution: Use Parameterized Queries
Although formatting the DateTime value as a string resolves the issue temporarily, the best solution is to use parameterized queries. Parameterized queries not only eliminate date conversion issues but also improve security and prevent SQL injection attacks.

Here’s how to refactor the code to use parameterized queries:
string query = @"insert into ContactInfo
(FirstName, LastName, MobileNo, Email, Country, State, City,
 APIType, AppName, Reason, ReasonComment, Message,
 CompanyName, ContactPerson, usertype, indCompanyName, date)
values
('-', '-', @MobileNo, @Email, @Country, @State, @City,
 @APIType, @AppName, @Reason, @ReasonComment, @Message,
 @CompanyName, @ContactPerson, @usertype, @indCompanyName, @date)";

Now, create the parameters:
SqlParameter[] param =
{
    new SqlParameter("@MobileNo", Contact1.Text),
    new SqlParameter("@Email", Email.Text.Replace(" ", "")),
    new SqlParameter("@Country", drpCountry.SelectedItem.Text),
    new SqlParameter("@State", state),
    new SqlParameter("@City", city),
    new SqlParameter("@APIType", Assestlist),
    new SqlParameter("@AppName", SiteName.Text),
    new SqlParameter("@Reason", drpApi.SelectedValue),
    new SqlParameter("@ReasonComment", usercomment),
    new SqlParameter("@Message", txtMessage.Text),
    new SqlParameter("@CompanyName", Fname.Text),
    new SqlParameter("@ContactPerson", Lname.Text),
    new SqlParameter("@usertype", usertype),
    new SqlParameter("@indCompanyName", infocompany.Text),
    new SqlParameter("@date", SqlDbType.DateTime) { Value = DateTime.Now }
};

SqlHelper.ExecuteNonQuery(SQL, CommandType.Text, query, param);

Explanation of Parameterized Queries
Avoids String Concatenation: Using parameters means we no longer have to manually concatenate user inputs or DateTime values into the query string. This approach helps prevent errors and SQL injection attacks.

SQL Parameters: We pass the DateTime.Now value as a parameter with the correct type (SqlDbType.DateTime). SQL Server handles the conversion, ensuring it is always in the correct format.

Prevents SQL Injection: By using parameters, we avoid manually building the query string, which protects the application from SQL injection attacks.

Conclusion
The "The conversion of a varchar data type to a datetime data type resulted in an out-of-range value" error occurs when SQL Server attempts to convert a string (often from DateTime.Now) into a DateTime value, and the format is not understood. The most straightforward fix is to format the date as an ISO-compliant string. However, the best practice is to use parameterized queries, which not only resolve the issue but also enhance security, maintainability, and performance.

Summary

• Temporary fix: Format DateTime as yyyy-MM-dd HH:mm:ss.
• Long-term solution: Use parameterized queries to prevent errors and SQL injection.

This approach ensures that your application works reliably across different environments and is easier to maintain in the long run.

HostForLIFE ASP.NET Core 10.0 Hosting

European Best, cheap and reliable ASP.NET Core 10.0 hosting with instant activation. HostForLIFE.eu is #1 Recommended Windows and ASP.NET hosting in European Continent. With 99.99% Uptime Guaranteed of Relibility, Stability and Performace. HostForLIFE.eu security team is constantly monitoring the entire network for unusual behaviour. We deliver hosting solution including Shared hosting, Cloud hosting, Reseller hosting, Dedicated Servers, and IT as Service for companies of all size.

Selecting the best database provider for ASP.NET Core enterprise-grade apps has a direct impact on performance, scalability, maintainability, and cloud strategy. It's not merely a technical choice.

With the help of actual coding examples, we will examine the many kinds of database providers that are available in ASP.NET Core, their internal operations, how to select the best database provider, and when to use each.

1. Comprehending ASP.NET Core Database Providers
A database is not directly communicated with by ASP.NET Core. Rather, it depends on:

• ADO.NET providers
• Entity Framework Core database providers
• Micro-ORM providers (like Dapper)
• NoSQL SDK providers
• In-memory providers for testing
• The abstraction layer allows you to switch providers without rewriting your business logic.
• The most common abstraction used today is Entity Framework Core (EF Core).

2. Entity Framework Core Relational Providers
EF Core supports multiple relational database engines through pluggable providers.

2.1 SQL Server Provider
Package:
Microsoft.EntityFrameworkCore.SqlServer

Best for:

• Enterprise systems
• Azure-hosted apps
• Microsoft ecosystem environments

Setup Example
Install package:
dotnet add package Microsoft.EntityFrameworkCore.SqlServer

Register in Program.cs:
builder.Services.AddDbContext<AppDbContext>(options =>
options.UseSqlServer(
    builder.Configuration.GetConnectionString("DefaultConnection")));

Connection string (appsettings.json):
"ConnectionStrings": {
  "DefaultConnection": "Server=.;Database=AppDb;Trusted_Connection=True;"
}

Production scenario:

• Banking systems
• ERP systems
• Applications using SQL Server Always On

2.2 PostgreSQL Provider
Package:
Npgsql.EntityFrameworkCore.PostgreSQL

Best for:

• Linux deployments
• Cloud-native systems
• Cost-optimized production environments

Setup Example
dotnet add package Npgsql.EntityFrameworkCore.PostgreSQL
    builder.Services.AddDbContext<AppDbContext>(options =>
    options.UseNpgsql(
        builder.Configuration.GetConnectionString("PostgresConnection")));

Connection string:
"PostgresConnection": "Host=localhost;Database=AppDb;Username=postgres;Password=pass"

Real-world use case:

• SaaS multi-tenant platforms
• Kubernetes deployments

2.3 MySQL / MariaDB Provider
Package:
Pomelo.EntityFrameworkCore.MySql

Setup:
builder.Services.AddDbContext<AppDbContext>(options =>
    options.UseMySql(
        builder.Configuration.GetConnectionString("MySqlConnection"),
        ServerVersion.AutoDetect(
            builder.Configuration.GetConnectionString("MySqlConnection"))));
Best for:

• Hosting providers
• PHP-to-.NET migration projects

2.4 SQLite Provider
Package:
Microsoft.EntityFrameworkCore.Sqlite

Use cases:

• Desktop apps
• Mobile apps
• Lightweight internal tools

Example:
builder.Services.AddDbContext<AppDbContext>(options =>
options.UseSqlite("Data Source=app.db"));

Common in:

• Proof of Concepts
• Edge deployments

3. In-Memory Provider (Testing)
Package:
Microsoft.EntityFrameworkCore.InMemory

Important: Not a real relational database.
Used for:

• Unit testing
• Integration testing

Example:
builder.Services.AddDbContext<AppDbContext>(options =>
options.UseInMemoryDatabase("TestDb"));

Example test:
[Fact]
public void AddUser_ShouldSaveUser()
{
    var options = new DbContextOptionsBuilder<AppDbContext>()
        .UseInMemoryDatabase("TestDb")
        .Options;

    using var context = new AppDbContext(options);
    context.Users.Add(new User { Name = "John" });
    context.SaveChanges();

    Assert.Equal(1, context.Users.Count());
}

Tip: Use SQLite in-memory mode instead for realistic relational behavior.

4. NoSQL Database Providers
ASP.NET Core also supports NoSQL databases via dedicated SDKs.

4.1 MongoDB
Package:
MongoDB.Driver

Setup:
builder.Services.AddSingleton<IMongoClient>(
new MongoClient(builder.Configuration["MongoSettings:Connection"]));

Repository example:
public class UserRepository
{
    private readonly IMongoCollection<User> _collection;

    public UserRepository(IMongoClient client)
    {
        var database = client.GetDatabase("AppDb");
        _collection = database.GetCollection<User>("Users");
    }

    public async Task CreateAsync(User user)
    {
        await _collection.InsertOneAsync(user);
    }
}

Use cases:

• Event-driven systems
• High write throughput
• Flexible schema applications

4.2 Azure Cosmos DB
Provider:
Microsoft.EntityFrameworkCore.Cosmos

Setup:
builder.Services.AddDbContext<AppDbContext>(options =>
    options.UseCosmos(
        builder.Configuration["Cosmos:AccountEndpoint"],
        builder.Configuration["Cosmos:AccountKey"],
        databaseName: "AppDb"));

Best for:

• Globally distributed apps
• Multi-region SaaS

5. Micro-ORM Providers (Dapper)
Sometimes EF Core is overkill.
Dapper works directly on ADO.NET providers.

Install:
dotnet add package Dapper

Example:
using (var connection = new SqlConnection(connectionString))
{
    var users = await connection.QueryAsync<User>(
        "SELECT * FROM Users WHERE IsActive = @IsActive",
        new { IsActive = true });
}

Use cases:

• High-performance APIs
• Read-heavy services
• Reporting microservices

6. ADO.NET Native Providers
Low-level database access.

Example with SQL Server:
using SqlConnection connection = new SqlConnection(connectionString);
await connection.OpenAsync();

SqlCommand command = new SqlCommand(
    "SELECT COUNT(*) FROM Users", connection);

int count = (int)await command.ExecuteScalarAsync();

Best for:

• Extreme performance scenarios
• Legacy migrations

7. Switching Providers Without Changing Business Logic
One of EF Core’s biggest strengths is provider abstraction.

Example:
Change:
options.UseSqlServer(...)

To:
options.UseNpgsql(...)

If your code avoids provider-specific features, everything works without changes.

Advice: Avoid raw SQL that ties you to one engine unless necessary.

8. How to Choose the Right Provider
Consider:

Hosting environment (Azure, AWS, on-prem)

• Licensing cost
• Team expertise
• Scalability requirements
• Transaction complexity
• Reporting needs
• Cloud-native architecture

Enterprise rule of thumb:

• Traditional enterprise system → SQL Server
• Open-source cloud-native → PostgreSQL
• Document-driven → MongoDB
• Globally distributed → Cosmos DB
• High-performance microservice → Dapper

9. Production Best Practices

• Always use connection pooling
• Enable retry policies
• Use migrations responsibly
• Monitor slow queries
• Avoid N+1 problems
• Use async methods
• Configure proper indexing

Example enabling retry logic:
options.UseSqlServer(connectionString,
    sqlOptions => sqlOptions.EnableRetryOnFailure());

Key Takeaways
Database providers in ASP.NET Core are not just interchangeable components — they define how your system scales, performs, and evolves.

The power of ASP.NET Core lies in its provider abstraction model. You can build your domain logic once and swap infrastructure as needed.

As architects and senior developers, our responsibility is not just to make it work — but to make it scalable, testable, and future-ready.

If you’d like, I can also write a follow-up deep dive on:

• EF Core performance tuning
• Multi-database architecture
• Read/write splitting
• Multi-tenant database strategies
• Hybrid relational + NoSQL systems

Happy Coding!

I write about modern C#, .NET, and real-world development practices. Follow me on C# Corner for regular insights, tips, and deep dives.

HostForLIFE ASP.NET Core 10.0 Hosting

European Best, cheap and reliable ASP.NET Core 10.0 hosting with instant activation. HostForLIFE.eu is #1 Recommended Windows and ASP.NET hosting in European Continent. With 99.99% Uptime Guaranteed of Relibility, Stability and Performace. HostForLIFE.eu security team is constantly monitoring the entire network for unusual behaviour. We deliver hosting solution including Shared hosting, Cloud hosting, Reseller hosting, Dedicated Servers, and IT as Service for companies of all size.

One of the most potent functions of the.NET runtime is Garbage Collection (GC). Manual memory allocation and deallocation are no longer necessary because it handles memory automatically. However, excessive allocations can result in GC pressure, which can cause latency spikes, throughput degradation, and higher CPU consumption in high-performance systems like APIs, microservices, real-time systems, and background processing applications.

Even though Microsoft's.NET platform is highly optimized for modern apps, developers still need to create memory-conscious code to get the best performance. This essay will explain GC pressure, its causes, and workable solutions for lowering it in contemporary.NET programs.

What is GC Pressure?
GC pressure occurs when an application creates too many short-lived objects or allocates large objects frequently, forcing the Garbage Collector to run more often.

When GC runs frequently:

• CPU usage increases
• Application pauses may occur
• Latency spikes become visible
• Throughput decreases

In high-load environments, this directly impacts scalability and user experience.

Understanding .NET Garbage Collection (High-Level)
The .NET GC is generational:

• Generation 0 (Gen 0) – Short-lived objects
• Generation 1 (Gen 1) – Transitional objects
• Generation 2 (Gen 2) – Long-lived objects
• Large Object Heap (LOH) – Objects typically larger than 85KB

Frequent Gen 0 collections are normal. However, frequent Gen 2 collections and LOH allocations can significantly hurt performance.

The goal is not to eliminate GC — it is to reduce unnecessary allocations.

Common Causes of GC Pressure

• Excessive object creation inside loops
• Large temporary allocations
• Frequent string concatenations
• Boxing and unboxing
• Improper use of LINQ
• Allocating new objects in hot paths
• Large collections frequently resized
• Not reusing buffers

Understanding these patterns is the first step toward optimization.

Practical Strategies to Reduce GC Pressure
1. Minimize Allocations in Hot Paths
Hot paths are sections of code executed frequently (e.g., API endpoints, background jobs).

Reduce:

• Temporary object creation
• Unnecessary list allocations
• Per-request object instantiations

Even small allocations multiplied by thousands of requests per second can significantly increase GC load.

2. Use Object Pooling
Object pooling allows you to reuse expensive objects instead of creating new ones repeatedly.

Pooling is especially useful for:

• Large buffers
• String builders
• Serialization objects
• Database-related objects

Reusing objects reduces heap allocations dramatically.

3. Prefer Structs Carefully
Value types (structs) are allocated on the stack in many scenarios and reduce heap allocations.

However:

• Avoid large structs
• Avoid excessive copying
• Use readonly structs when possible

Structs are powerful but must be used wisely.

4. Avoid Boxing and Unboxing
Boxing occurs when a value type is converted into an object type, causing heap allocation.

This often happens with:

• Non-generic collections
• Interface-based calls
• Implicit conversions

Prefer generic collections and strongly typed APIs to avoid hidden allocations.

5. Optimize String Handling
Strings are immutable in .NET. Excessive string concatenation creates many temporary objects.

Better approaches:

• Reuse string builders
• Avoid unnecessary formatting
• Cache repeated strings

String-heavy applications often suffer from unexpected GC pressure.

6. Use Span and Memory for High-Performance Scenarios
Modern .NET provides memory-efficient abstractions like Span and Memory that reduce heap allocations.

These are ideal for:

• Parsing
• Serialization
• Buffer manipulation
• High-throughput systems

They allow safe memory access without additional allocations.

7. Reduce Large Object Heap Allocations
Allocations larger than ~85KB go to the Large Object Heap (LOH).

Frequent LOH allocations:

• Are expensive
• Can fragment memory
• Trigger full Gen 2 collections

Strategies:

• Reuse large buffers
• Split large objects when possible

Avoid creating large temporary arrays

8. Avoid Overusing LINQ in Performance-Critical Code
LINQ improves readability but may generate intermediate allocations.

In performance-sensitive code:

• Replace complex LINQ chains with loops
• Avoid multiple enumerations
• Avoid unnecessary projections

Readability is important, but performance-sensitive code requires discipline.

9. Monitor and Measure
Optimization without measurement is guesswork.

Use profiling tools to monitor:

• Allocation rate
• GC collections per second
• Gen 2 collection frequency
• LOH allocations

Performance tuning should always be data-driven.

When Should You Optimize?
Not every application needs aggressive memory optimization.

You should focus on reducing GC pressure when:

• Your API has high throughput
• You see latency spikes
• CPU usage is high
• GC time is noticeable in monitoring
• You're building real-time systems

Premature optimization is harmful. Target hot paths only.

Real-World Impact
Reducing GC pressure results in:

1. Lower latency
2. Higher throughput
3. Better scalability
4. Reduced cloud costs
5. More predictable performance

In modern distributed systems, even small improvements in memory efficiency can significantly reduce infrastructure costs.

Conclusion
Garbage Collection in .NET is highly optimized and reliable. However, excessive memory allocations create unnecessary GC pressure that impacts performance and scalability.  By minimizing allocations, reusing objects, optimizing string usage, avoiding boxing, and carefully designing hot paths, developers can dramatically improve application performance.

Reducing GC pressure is not about fighting the runtime. It is about writing smarter, allocation conscious code. For developers building high-performance ASP.NET Core APIs, microservices, or real-time systems, understanding and reducing GC pressure is an essential skill in modern .NET development.

Reduce Server Load, Increase Performance and Expand Your Apps
Web apps with a lot of traffic require minimal latency and quick reaction times. Caching, or temporarily storing data or output so it can be reused rather than recalculated on each request, is a tried-and-true method of accomplishing this.

We can make advantage of the Response Caching Middleware that comes with ASP.NET Core. NCache is one of the best distributed caching options available when multi-server deployments and scalability are needed.

This blog post describes response caching, the benefits of using NCache, and the detailed steps for integrating NCache into an ASP.NET Core MVC application.

Caching
Caching is a performance optimization technique that stores frequently accessed application data or pre-generated output in a temporary, high-speed memory location. This allows subsequent requests for the same information to be served immediately without re-processing logic or querying the database.

By eliminating repetitive computation and reducing database or API calls, caching significantly lowers CPU usage, minimizes network traffic, decreases latency, and delivers faster response times.

In simple words, caching stores application data or page output in memory across HTTP requests — making repeated requests load instantly, reducing CPU and database usage, and improving user experience.

Response Caching
Response caching is a technique where the final HTTP response (the output sent back to the browser or client) is temporarily stored so that identical future requests can be served directly from the cache, without re-running controller code, database queries, or application logic.

In a typical request–response model, every time a user requests a resource — such as a webpage, API result, or image — the server executes a full pipeline:

• Routing
• Authentication
• Business logic execution
• Data access
• View rendering
• Response generation

This entire process consumes time and server resources.

With response caching, once a specific request is processed for the first time, the server saves the generated response in memory or a distributed cache. If another request for the same resource is made within a valid time window, the server instantly returns the cached response instead of executing the pipeline again.

Why Response Caching Matters?

• Avoids executing heavy controller logic repeatedly
• Reduces database or API calls
• Speeds up page or API response times
• Saves CPU, memory, and network resources
• Helps handle high user load and peak traffic

Simple Example
Without Response Caching

• User requests: GET /product-list
• Server fetches product data from the database
• Applies business logic and formats output
• Sends response to browser

This process repeats for every request.

With Response Caching

• First request is processed normally and stored in cache
• Subsequent requests retrieve the saved response instantly — with zero re-processing

When to Use Response Caching
Response caching is ideal for:

• Static content (HTML, CSS, JavaScript, banners, images)
• Pages or APIs that rarely change (FAQs, product catalogues, configuration data)

Public content requested repeatedly by many users
Example header:

• Cache-Control: max-age=90
• This means the browser can reuse the response for 90 seconds before requesting fresh data from the server.
• Response caching is best suited for static or rarely updated content such as CSS files, JavaScript bundles, banners, and static HTML pages.

NCache for Distributed Response Caching
ASP.NET Core applications often run across multiple servers — behind a load balancer, in a web farm, or across cloud containers. In such environments, traditional in-memory caching becomes ineffective because:

• Each server maintains its own memory
• Cached data on Server A is not available on Server B
• A user's next request may reach a different server, causing a cache miss
• This results in inconsistency, duplicate processing, and wasted resources.
• NCache is a high-performance, open-source distributed caching solution designed for high-transaction .NET applications. It delivers fast and linearly scalable in-memory data caching, significantly reducing database calls and eliminating performance bottlenecks.
• NCache acts as a shared distributed caching layer. Instead of each server storing its own cache, all servers connect to a central NCache cluster and share cached items in real time.

This ensures:

• Data cached by one server becomes instantly available to all servers
• Response caching remains consistent and synchronized
• The application scales efficiently to handle millions of requests

Setting Up NCache in ASP.NET Core (Step-by-Step)
Step 1: Create a New MVC Project

• Open Visual Studio
• Click "Create a New Project"
• Select "ASP.NET Core Web Application"
• Choose "Web Application (Model-View-Controller)"
• Target .NET Core 3.0 or later

Disable Authentication, Docker, and HTTPS (for demo purposes)
Step 2: Install NCache NuGet Package

Open Package Manager Console and run:
Install-Package NCache.Microsoft.Extensions.Caching

Add namespace in Startup.cs:

using Alachisoft.NCache.Caching.Distributed;

Step 3: Enable Response Caching Middleware
In Startup.cs → ConfigureServices():
public void ConfigureServices(IServiceCollection services)
{
    services.AddResponseCaching();
    services.AddMvc();
}

Add middleware in Configure():
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    app.UseResponseCaching();
}

Step 4: Configure NCache as Distributed Cache
You can configure NCache using appsettings.json or via IOptions.

Option A: Configure via appsettings.json
{
  "NCacheSettings": {
    "CacheName": "MyDistributedCache",
    "EnableLogs": "True",
    "RequestTimeout": "60"
  }
}

Add configuration in Startup:
public void ConfigureServices(IServiceCollection services)
{
    services.AddResponseCaching();
    services.AddNCacheDistributedCache(Configuration.GetSection("NCacheSettings"));
    services.AddMvc();
}

Option B: Configure Using IOptions in Code
public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc();
    services.AddNCacheDistributedCache(options =>
    {
        options.CacheName = "MyDistributedCache";
        options.EnableLogs = true;
        options.ExceptionsEnabled = true;
    });
}

Using Response Caching in Action Methods
Apply the ResponseCache attribute to controller actions:
public class HomeController : Controller
{
    [ResponseCache(Duration = 60, Location = ResponseCacheLocation.Any, NoStore = false)]
    public IActionResult GetData()
    {
        return Content("Cached Response Example");
    }
}

Summary

• Caching is essential for building high-performance ASP.NET Core applications.
• Response caching reduces latency and improves scalability.
• NCache is a powerful distributed caching solution ideal for multi-server environments.
• ASP.NET Core integrates seamlessly with NCache using middleware and distributed cache configuration.

Developers must use platform agnostic development practices that go beyond simply picking the appropriate framework in order to guarantee that a .NET Core application is genuinely cross platform. Internal logic, including file path handling, time zone management, and dependency selections, might result in an application crashing when it is deployed to a non Windows environment, even if the framework supports Windows, Linux, and macOS.  In order to make the project really cross-platform compatible, this tutorial has been enhanced to include detailed technical context and practical patterns.

Introduction: The Compatibility Gap
Choosing .NET 8.0 is only the beginning of a cross-platform journey. Many developers assume that "cross-platform framework" means "automatically compatible code," but hard-won lessons from enterprise migrations show that architectural decisions and coding habits are the primary factors in production success. To build a reliable system, you must design for platform independence from the start.

1. Solving the "Silent Killer": File Path Handling
Improper file path handling is a leading cause of migration failure because Windows uses backslashes (\) while Linux and macOS use forward slashes (/).

• Physical File Systems: Never hardcode separators. Always use Path.Combine(), which automatically selects the correct separator for the host OS.
• Virtual and Web Paths: For URLs, web paths, or database entries, use forward slashes (/) consistently, as they are the global web standard.
• Path Normalization: When your code converts a physical disk path to a virtual web path, you must normalize it by explicitly replacing backslashes with forward slashes to ensure it works in a web context regardless of the source OS.

Example: Robust Path Construction
// Physical path (OS-agnostic)
var physicalPath = Path.Combine("App_Data", "Documents", fileName);

// Normalizing for virtual web use
var virtualPath = physicalPath.Replace(@"\", "/", StringComparison.Ordinal);

2. Eliminating Hidden Windows Dependencies
Your .csproj files often harbor settings that silently block Linux builds or trigger runtime errors.

• Audit Project Files: Remove desktop-specific tags like UseWPF or UseWindowForms for web APIs and console apps. These pull in Windows-only dependencies that do not exist on Linux.
• Explicit Platform Guarding: If a specific service must use a Windows API (like the Registry), hide it behind a platform-agnostic interface and use the [SupportedOSPlatform("windows")] attribute to document the requirement.

3. Cross-Platform Graphics: The Move to ImageSharp
The legacy System.Drawing.Common library relies on Windows GDI+, which requires a problematic compatibility layer libgdiplus on Linux.

• The Modern Alternative: Use SixLabors.ImageSharp. It is a fully managed, cross-platform library with no native dependencies, ensuring identical behavior across all distributions.
• Safe Usage of System.Drawing: The System.Drwaing.Color struct is a safe exception; it is a simple data structure for ARGB values and does not require native Windows libraries.

4. Handling System Information and Environment
Accessing server data requires patterns that account for differing variable names across operating systems.

• User Identification: Use Environment.UserName which is built to work reliably on both Windows and Linux.
• Reliable OS Detection: Use RuntimeInformation.IsOSPlatform() rather than checking environment strings to execute OS-specific logic.
• Environment Variable Fallbacks: Windows uses USERNAME while Linux uses USER. Implement a fallback pattern to ensure your application can find identity data on any host.

5. Database and Timezone Management
Database connectivity and time calculations are common points of failure during Linux deployments.

• MongoDB Best Practices: Keep connections simple. Avoid Windows-specific socket configurations and load connection strings from environment variables or configuration files.
• The IANA Standard: Windows uses "India Standard Time," but Linux requires IANA IDs like "Asia/Kolkata". In .NET 6 and higher, IANA IDs are supported natively on Windows; for older versions, utilize the TimeZoneConverter library to bridge the gap.

6. Performance-First File I/O
Synchronous file operations can lead to thread pool starvation and performance degradation.

• Prioritize Async: Always use asynchronous methods such as ReadAllBytesAsync and WriteAllBytesAsync.
• Defensive I/O: Always check for the existence of a directory or file before attempting an operation to avoid platform-specific exception handling issues.

7. Security and Certificate Paths
Security related files like HTTPS/TLS certificates or API keys are critical. Hardcoded paths for these files will break authentication on Linux.

• Configuration Over Hardcoding: Store certificate paths in your app config or environment variables.
• Dynamic Resolution: Use Path.Combine(AppDomain.CurrentDomain.BaseDirectory, ...) to resolve security file locations dynamically relative to the application's root.

8. The Testing Strategy: Docker and WSL2
Testing on Windows is no longer sufficient for modern .NET development.

• Containerization: Use a Dockerfile to build and run your application in a Linux runtime during development to catch platform issues early.
• WSL2: Use the Windows Subsystem for Linux to run endpoints and verify file system logic without needing a separate server.
• CI/CD Integration: Configure your automated pipelines (like GitHub Actions) to run tests on ubuntu-latest to ensure every commit is Linux-compatible.

Checklist for Cross-Platform Success

Conclusion

Cross platform development success is a state of mind. You can future proof your application, lower infrastructure costs, and guarantee deployment flexibility across any cloud or local environment by making all paths, system calls, and dependencies platform agnostic. Thank you, and keep checking back for more!

Let's begin with a straightforward example. Imagine a concert hall where individual water bottles are distributed; each time someone requests one, they receive a fresh one. While other guests have their own chairs, we are assigned to the same one for the duration of our visit. Additionally, there is just one stage in the entire stadium, which is used by everyone from the time the doors open until the event concludes.

In this case, the stage service is singular, the bottle distribution service is transient, and the seat assignment service is scoped (one per request). Dependency Injection is the key engine used in contemporary.NET development to connect an application, guaranteeing that the code is both testable and manageable. A crucial question that emerges as a project grows is how long a service should last. Choosing the incorrect length might result in memory leaks and elusive bugs, which has a direct influence on memory management, performance under load, and data integrity.

Every lifetime choice and its practical ramifications for any architecture are examined in this article. Understanding these durations makes it feasible to select the best registration for each unique use case while maintaining a system's speed and predictability.

Lifetimes of Services in.NET
In.NET, the duration of an object's existence following its creation by the Dependency Injection container is determined by its service lifespan. Each registration has a time limit that tells the system whether to create a new instance for each request, preserve a single instance for the length of the application, or reuse one instance within a single web session.

Because services have varied duties, this decision is crucial. While services that manage costly resources or shared states benefit from reuse, lightweight, stateless logic is best for frequent recreation. The three options offered by the framework—Transient, Scoped, and Singleton—each have a specific function in preserving an architecture that is quick, reliable, and memory-efficient.

Why it matters

Service lifetimes are fundamental to runtime behavior, dictating whether the container provides a fresh instance or a shared one. This decision directly impacts memory efficiency, thread safety, and data consistency. Selecting the wrong duration can trigger runtime exceptions, create race conditions, or cause performance-draining memory leaks.

Correct lifecycle management ensures that services remain safe, efficient, and properly isolated. It prevents hidden bugs that typically only surface under heavy production load. Every registration requires a deliberate choice to ensure the service exists exactly as long as necessary for its specific responsibility.

Lets discuss each in detail.

1. Transient Lifetime
Transient service is generated every time it is requested from the DI container. There is no caching or reuse; it is the most isolated form of instantiation available. This makes it the best choice for lightweight, stateless services—like utilities, validators, or builders—that do not store data and don’t require complex lifecycle management.
// Each request for the interface receives a completely fresh instance
builder.Services.AddTransient<IPasswordHasher, Argon2Hasher>();

The Behavior:

• Every injection point receives a fresh instance.
• If one HTTP request asks for the service three times, it receives three separate copies.

Best For:

• Stateless Tools: Mappers, formatters, or mathematical calculators.
• Validation: Lightweight rules engines that don't store data.

The Pitfall: Avoid using this for "expensive" objects that are slow to build, as creating them repeatedly can strain performance and trigger constant garbage collection.

The Rule of Thumb: Use Transient for lightweight, independent services where sharing state is unnecessary.

2. Scoped Lifetime
A Scoped service is created once per HTTP request and shared across all components handling that specific request. It is the ideal choice for services that need to maintain state or context across different layers but must be reset once the request ends.

builder.Services.AddScoped<IUserContext, HttpUserContext>();

The Behavior:

• One instance per request: The same instance is reused for every injection within a single scope.
• Isolation: A brand-new instance is created for the next user or request, ensuring no data leaks between different users.

Best For:

• Data Access: Entity Framework’s DbContext is the classic example.
• User Context: Tracking the current user’s identity or permissions throughout a request.

Unit of Work: Managing a shared transaction across multiple services.

The Pitfall: Avoid injecting a Scoped service into a Singleton. This leads to "Captive Dependency" errors, where the short-lived service is trapped forever in a long-lived one, causing stale data or crashes.

The Rule of Thumb: Use Scoped for services that need to share data or resources consistently within a single request.

3.Singleton Lifetime
Singleton service is instantiated exactly once when the application starts and is reused everywhere until the app shuts down. It is registered once, built once, and shared across all threads and requests, making it ideal for efficient, global resource management.
builder.Services.AddSingleton<ITimeProvider, UtcTimeProvider>();

The Behavior:

• One instance only: The same instance is injected everywhere across the entire application's lifecycle.
• Global Access: Every user and every request shares this single object instance.

Best For:

• Global Configuration: Providing application settings or feature flags.
• Caching Services: Storing data in memory for fast retrieval by all users.
• System Utilities: Logging, time tracking services, and background workers that run continuously.

The Pitfall: A Singleton must be entirely thread-safe. Avoid storing mutable, request-specific data in it, and critically, do not inject any Scoped or Transient services that manage their own disposal, as this will lead to "Captive Dependency" errors or crashes.

The Rule of Thumb: Use a Singleton only for services that are safe to share globally and live for the entire duration of the application.
How the .NET DI Container Manages Service Lifetimes

The built-in .NET DI container (Microsoft.Extensions.DependencyInjection) is a high-performance engine designed for efficiency and thread safety. It manages object lifecycles by combining service descriptors with internal scope tracking.

Here is the internal process that occurs whenever a service is requested:

1. Service Registration
Each call to AddTransient, AddScoped, or AddSingleton populates the IServiceCollection with a ServiceDescriptor. This descriptor acts as a blueprint, storing the service type, its implementation, and its intended lifetime. Once registration is complete, these blueprints are used to build the final ServiceProvider.

2. Resolving Services
When an application requests a service, the ServiceProvider determines how to provide it based on its lifetime:

• Singleton: Stored in a root-level cache and reused for the life of the application.
• Scoped: Stored in a cache tied to a specific IServiceScope (usually one HTTP request); it is reused only within that scope.
• Transient: Never cached; a fresh instance is created every time the constructor or factory is invoked.

3. Scope Management
In web applications, the framework automatically creates a new scope at the start of every HTTP request. This scope acts as a temporary container that holds all "Scoped" services until the request completes. Injecting IServiceScopeFactory allows for the manual creation of these boundaries outside the standard web pipeline.'

4. Automatic Disposal
The container tracks any service that implements IDisposable:

• Singletons are disposed only when the application shuts down.
• Scoped services are disposed immediately when the request or manual scope ends.
• Transient services are disposed by the container only if it "owns" the instance, meaning it was resolved through the standard DI tree.

5. Performance and Thread Safety
The built-in container is thread-safe for service resolution, meaning multiple users can request services simultaneously without crashing. To maintain high performance, .NET avoids slow runtime reflection by precomputing how to call constructors. However, thread safety inside the service itself—especially for Singletons—remains the responsibility of the developer.

Understanding this internal mechanics prevents common issues, such as services being disposed of too early or instances being shared unexpectedly. While the system is lightweight, it is robust enough to handle the vast majority of enterprise scenarios without needing external libraries

Conclusion
In this article we have seen mastering service lifetimes is essential for application stability. Correctly applying Transient for lightweight tools, Scoped for request-specific logic, and Singleton for global resources prevents memory leaks and threading conflicts. Aligning these registrations with their intended roles ensures a high-performing and maintainable architecture. Hope this helps!

Logging is frequently necessary while dealing with ASP.NET applications, particularly for monitoring problems, API replies, or authentication events. When implementing file-based logging, the following runtime error is frequently encountered:

Could not find a part of the path
E:\2026 ProjectList\Project's\CoreConversation\ReferenceProject\~singlsignonlog\singlsignon_log13-01-26.txt

This error usually appears when calling File.AppendAllText() and indicates that the application is trying to write to a file location that does not exist or is incorrectly mapped.

Problematic Logging Code
Consider the following logging method used in an ASP.NET application:
public static void Singlsignon_log(string res)
{
    try
    {
        File.AppendAllText(
            HttpContext.Current.Server.MapPath(
                "~singlsignonlog/singlsignon_log" +
                DateTime.Now.ToString("dd-MM-yy") + ".txt"),
            "{" + DateTime.Now.ToString() + "} " + res + Environment.NewLine
        );
    }
    catch (Exception ex)
    {
        File.AppendAllText(
            HttpContext.Current.Server.MapPath(
                "~singlsignonlog/singlsignon_log" +
                DateTime.Now.ToString("dd-MM-yy") + ".txt"),
            "{" + DateTime.Now.ToString() + "} " + ex.Message + Environment.NewLine
        );
    }
}

At first glance, the code appears correct, but there are two critical issues that cause the exception.

Issue 1: Incorrect Use of Server.MapPath
In ASP.NET, the tilde (~) must always be followed by a forward slash. Using ~singlsignonlog instead of ~/singlsignonlog results in an invalid physical path being generated.

Issue 2: Directory Does Not Exist
The File.AppendAllText() method does not create directories automatically. If the singlsignonlog folder does not already exist in the application root, the method throws a "Could not find a part of the path" exception.

Because of these two issues, the application fails at runtime when it attempts to write the log file.

Correct and Safe Implementation
A safer approach is to resolve the folder path correctly and ensure that the directory exists before writing to the file. The revised method below fixes both problems:
public static void Singlsignon_log(string res)
{
    try
    {
        string folderPath =
            HttpContext.Current.Server.MapPath("~/singlsignonlog/");

        if (!Directory.Exists(folderPath))
        {
            Directory.CreateDirectory(folderPath);
        }

        string filePath = Path.Combine(
            folderPath,
            "singlsignon_log" +
            DateTime.Now.ToString("dd-MM-yy") + ".txt"
        );

        File.AppendAllText(
            filePath,
            "{" + DateTime.Now + "} " + res + Environment.NewLine
        );
    }
    catch
    {
        // Avoid logging inside catch to prevent recursive failures
    }
}

Why This Fix Works?
The virtual path is correctly written as ~/singlsignonlog/, ensuring that Server.MapPath resolves it to a valid physical directory
The code checks whether the directory exists and creates it if necessary
This prevents runtime exceptions related to missing folders

Additional Best Practices
Avoid performing file logging inside the catch block using the same logic. If logging fails for any reason, attempting to log the exception again can lead to repeated failures or even application crashes. In production systems, it is better to silently handle logging failures or route them to a fallback logging mechanism.

For real-world ASP.NET applications, it is also recommended to store log files inside the App_Data folder. This folder is designed for application data and helps avoid permission issues on hosting servers.

Conclusion
A small mistake in virtual path usage or directory validation can lead to runtime logging failures. By correcting Server.MapPath usage and ensuring directories exist before writing files, logging becomes reliable across development, testing, and production environments.

Microservices architecture has emerged as the go-to method for creating scalable and maintainable systems as contemporary applications continue to expand in size and complexity. Teams now divide functionality into smaller, independently deployable services rather than implementing a single, huge application. Method calls within the same process facilitate quick and easy communication in a monolithic program. Because microservices communicate over a network, there are issues with latency, partial failures, versioning, and security.

In this post, I'll examine the most popular microservices communication techniques, discuss when and why to utilize them, and show how to implement them in.NET 10.

Recognizing Communication Styles in Microservices
Two basic communication types are commonly used by microservices:

1. Concurrent Communication
The calling service awaits a prompt answer from another provider. Examples include gRPC and REST APIs.

2. Communication That Is Asynchronous
After sending a message or event, the calling service proceeds with processing without waiting for a reply. Examples include message queues and platforms for streaming events.

Depending on performance requirements and business needs, the majority of production systems combine the two.

1. RESTful APIs (HTTP-Based Communication)
REST remains the most common and accessible communication mechanism in microservices. It relies on standard HTTP methods and usually exchanges data in JSON format.

Despite newer alternatives, REST continues to be relevant due to its simplicity, tooling support, and compatibility with browsers and external clients.

When REST Is the Right Choice

• Client-facing or public APIs
• Simple request–response workflows
• Scenarios where readability and debuggability matter
• Integration with third-party systems

RestAPI
Example: Product Microservice Using ASP.NET Core (.NET 10)
[ApiController]
[Route("api/products")]
public class ProductController : ControllerBase
{
    [HttpGet]
    public IActionResult GetProducts()
    {
        return Ok(new[] { "Laptop", "Tablet", "Mobile" });
    }

    [HttpPost]
    public IActionResult CreateProduct(Product product)
    {
        return Ok(product);
    }
}

Why REST Still Works Well?

• Easy to understand and maintain
• Mature ecosystem (Swagger, OpenAPI, Postman)
• Language and platform independent

Limitations to Be Aware Of

• JSON serialization increases payload size
• Higher latency for internal service-to-service calls
• Tight coupling due to synchronous request–response flow

2. gRPC – High-Performance Internal Communication
gRPC is designed for efficient, low-latency communication between internal services. It uses Protocol Buffers (Protobuf) for binary serialization and runs over HTTP/2, making it significantly faster than REST.

With .NET 10, gRPC continues to be a first-class citizen, especially for service-to-service communication inside a controlled environment.

Ideal Use Cases for gRPC

• Internal microservice communication
• High-throughput systems
• Real-time or streaming scenarios
• Strict API contract enforcement

Define the Service Contract (greet.proto)
syntax = "proto3";

option csharp_namespace = "GrpcService1";

package greet;

// The greeting service definition.
service Greeter {
  // Sends a greeting
  rpc SayHello (HelloRequest) returns (HelloReply);
}

Implement gRPC Service in .NET 10
namespace GrpcService1.Services
{
    public class GreeterService(ILogger<GreeterService> logger) : Greeter.GreeterBase
    {
        public override Task<HelloReply> SayHello(HelloRequest request, ServerCallContext context)
        {
            logger.LogInformation("The message is received from {Name}", request.Name);

            return Task.FromResult(new HelloReply
            {
                Message = "Hello " + request.Name
            });
        }
    }
}

Key Benefits

• Very fast serialization and transport
• Strongly typed, contract-first design
• Built-in support for streaming

Trade-Offs

• Payloads are not human-readable
• Requires tooling for debugging
• Limited direct browser support

3. Message Queues – Asynchronous and Event-Driven Communication
Message queues enable asynchronous communication, allowing services to exchange messages without knowing about each other’s availability or location. This approach is fundamental to event-driven architectures.

Technologies like RabbitMQ, Apache Kafka, and cloud-based queues are commonly used with .NET microservices.

When Message Queues Are the Best Fit?

• Background processing
• Event publishing (e.g., OrderCreated)
• Loose coupling between services
• High resilience and fault tolerance

Example: RabbitMQ Producer in .NET 10
var factory = new ConnectionFactory { HostName = "localhost" };

using var connection = factory.CreateConnection();
using var channel = connection.CreateModel();

channel.QueueDeclare("productQueue", false, false, false);

var body = Encoding.UTF8.GetBytes("ProductCreated");

channel.BasicPublish("", "productQueue", null, body);

Why Teams Choose Message Queues

• Services are loosely coupled
• Improved system stability
• Easy horizontal scaling

Challenges

• Increased infrastructure complexity
• Harder end-to-end tracing
• Requires idempotent message handling

4. Apache Kafka – Event Streaming at Enterprise Scale
Apache Kafka is a distributed event streaming platform built for massive scale. Unlike traditional queues, Kafka stores events durably and allows multiple consumers to read them independently.

Kafka is often used when events are core to the business domain.

Common Kafka Use Cases

• Event sourcing
• Audit logs
• Real-time analytics
• Data pipelines across systems

Kafka works best when teams embrace event-driven thinking rather than request–response models

Conclusions
Choosing how microservices communicate is a long-term architectural decision, not just a technology choice.

• REST prioritizes simplicity and accessibility
• gRPC delivers speed and contract safety
• Message queues enable resilience and scalability

Modern systems built with .NET 10 often combine all three approaches to meet evolving business and technical demands.