Safe JWT Verification in ASP.NET Core Using Cookie Storage.NET 9

JWT (JSON Web Token) authentication in ASP.NET Core can be implemented by storing the token inside an HTTP-only cookie to enhance security. This method blends the stateless and self-contained nature of JWTs with the added protection provided by secure cookie storage.

Why use JWT with cookies?

JWTs are widely used for authentication because they are stateless and carry all the required user data within the token itself. However, saving JWTs in localStorage or sessionStorage makes them vulnerable to XSS (Cross-Site Scripting) attacks. Placing the token in an HTTP-only cookie helps reduce this risk, while still preserving the advantages of JWT-based authentication.

Step 1: Configure JWT Authentication

To begin, configure JWT authentication in your ASP.NET Core application:

var jwtKey = "qwertyuiopasdfghjklzxcvbnm123456";
builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(options =>
    {
        options.TokenValidationParameters = new TokenValidationParameters
        {
            ValidateIssuer = true,
            ValidateAudience = true,
            ValidateLifetime = true,
            ValidateIssuerSigningKey = true,
            ValidIssuer = "your-app",
            ValidAudience = "your-app",
            IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(jwtKey))
        };

        // Read JWT token from cookie
        options.Events = new JwtBearerEvents
        {
            OnMessageReceived = context =>
            {
                if (context.Request.Cookies.ContainsKey("AuthToken"))
                {
                    context.Token = context.Request.Cookies["AuthToken"];
                }
                return Task.CompletedTask;
            }
        };
    });

builder.Services.AddAuthorization();

Step 2: Configure Middleware

app.UseAuthentication();
app.UseAuthorization();

add the authentication and authorization middleware in your Program.cs:

Step 3: Generate and Store JWT Tokens

Here's our token generation endpoint:

[HttpPost("GenerateAuthToken")]
public IActionResult GenerateAuthToken()
{
    var jwtKey = "qwertyuiopasdfghjklzxcvbnm123456";
    var token = GenerateJwtToken("Test", jwtKey);
    var cookieOptions = new CookieOptions
    {
        HttpOnly = true,     // Prevent JavaScript access
        Secure = true,       // Only send over HTTPS
        SameSite = SameSiteMode.Strict, // Prevent CSRF
        Expires = DateTime.UtcNow.AddHours(1)
    };

    Response.Cookies.Append("AuthToken", token, cookieOptions);

    return Ok(new { message = "Auth Token generated successfully" });
}

public static string GenerateJwtToken(string username, string key)
{
    var tokenHandler = new JwtSecurityTokenHandler();
    var keyBytes = Encoding.UTF8.GetBytes(key);

    var tokenDescriptor = new SecurityTokenDescriptor
    {
        Subject = new ClaimsIdentity(new[]
        {
            new Claim(ClaimTypes.Name, username)
        }),
        Expires = DateTime.UtcNow.AddHours(1),
        Issuer = "your-app",
        Audience = "your-app",
        SigningCredentials = new SigningCredentials(
            new SymmetricSecurityKey(keyBytes),
            SecurityAlgorithms.HmacSha256Signature)
    };

    var token = tokenHandler.CreateToken(tokenDescriptor);
    return tokenHandler.WriteToken(token);
}

Step 4: Protect Endpoints with Authorization

Now we can protect endpoints using the [Authorize] attribute:

[Authorize]
[HttpGet("GetCurrentProfile")]
public IActionResult GetCurrentProfile()
{
    var username = User.Identity?.Name;
    return Ok(new { user = username });
}

Full Example  : 

Here's a complete minimal API example:

var builder = WebApplication.CreateBuilder(args);

// Add services
var jwtKey = "qwertyuiopasdfghjklzxcvbnm123456";
builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(options =>
    {
        options.TokenValidationParameters = new TokenValidationParameters
        {
            ValidateIssuer = true,
            ValidateAudience = true,
            ValidateLifetime = true,
            ValidateIssuerSigningKey = true,
            ValidIssuer = "your-app",
            ValidAudience = "your-app",
            IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(jwtKey))
        };

        options.Events = new JwtBearerEvents
        {
            OnMessageReceived = context =>
            {
                if (context.Request.Cookies.ContainsKey("AuthToken"))
                {
                    context.Token = context.Request.Cookies["AuthToken"];
                }
                return Task.CompletedTask;
            }
        };
    });

builder.Services.AddAuthorization();
builder.Services.AddControllers();

var app = builder.Build();

app.UseAuthentication();
app.UseAuthorization();

app.MapControllers();

app.Run();

Security Considerations

1. Key Management: In production, use a more complex key and store it securely (e.g., in Azure Key Vault or AWS Secrets Manager)

2. Token Expiration: Keep token lifetimes short (1 hour in our example)

3. Refresh Tokens: Consider implementing a refresh token mechanism for longer sessions

Best ASP.NET Core 10.0 Hosting Recommendation

One of the most important things when choosing a good ASP.NET Core 8.0 hosting is the feature and reliability. HostForLIFE is the leading provider of Windows hosting and affordable ASP.NET Core, their servers are optimized for PHP web applications. The performance and the uptime of the hosting service are excellent and the features of the web hosting plan are even greater than what many hosting providers ask you to pay for. 

At HostForLIFEASP.NET, customers can also experience fast ASP.NET Core hosting. The company invested a lot of money to ensure the best and fastest performance of the datacenters, servers, network and other facilities. Its datacenters are equipped with the top equipments like cooling system, fire detection, high speed Internet connection, and so on. That is why HostForLIFEASP.NET guarantees 99.9% uptime for ASP.NET Core. And the engineers do regular maintenance and monitoring works to assure its Orchard hosting are security and always up.

Read More

How Can I fix the .NET Core Error "Unable to Resolve Service for Type"?

When the built-in Dependency Injection (DI) container in.NET Core is unable to instantiate a necessary service at runtime, the error message "Unable to resolve service for type" appears. One of the most frequent problems developers have while utilizing ASP.NET Core, Web APIs, Minimal APIs, background services, or microservices architecture is this exception.

Usually, this mistake manifests as:

InvalidOperationException: While trying to activate 'Y', service for type 'X' could not be resolved.

To put it simply, the framework is attempting to build an object (Y), but the Dependency Injection container does not have one of its dependents (X) registered.

Understanding how Dependency Injection functions internally in.NET Core is crucial to correctly resolving this issue.

Understanding Dependency Injection in .NET Core

Dependency Injection (DI) is a design pattern that enables loose coupling between components. In ASP.NET Core, services are registered in the IServiceCollection inside Program.cs (or Startup.cs in older versions). The framework automatically resolves dependencies via constructor injection.

Example:

public class ProductController : ControllerBase
{
private readonly IProductService _productService;

public ProductController(IProductService productService)
{
    _productService = productService;
}

}

If IProductService is not registered in the service container, the application throws the “Unable to resolve service” error at runtime.

Root Causes of the Error

There are several common causes behind this exception in .NET Core applications.

1. Service Not Registered in DI Container

This is the most frequent reason.

Problem:
IProductService is injected but not registered.

Solution:
Register it in Program.cs:

builder.Services.AddScoped<IProductService, ProductService>();

Choose the appropriate lifetime:

• AddTransient → New instance per request

• AddScoped → One instance per HTTP request

• AddSingleton → Single instance for entire application lifecycle

2. Incorrect Service Lifetime Configuration

Sometimes services are registered but with incompatible lifetimes.

Example Problem:
A Singleton service depends on a Scoped service.

This causes runtime failures because a longer-lived service cannot depend on a shorter-lived service.

Solution:
Align service lifetimes correctly or refactor dependencies.

3. Missing Concrete Implementation

If only an interface is injected but no implementation exists, DI cannot resolve it.

Incorrect:
builder.Services.AddScoped();

Correct:
builder.Services.AddScoped<IOrderService, OrderService>();

4. Typo or Namespace Mismatch

In large enterprise solutions with multiple projects, it is common to accidentally register the wrong interface or implementation from a different namespace.

Always verify:

• Correct interface type

• Correct implementation class

• Correct project reference

5. Constructor Injection Misconfiguration

If a constructor has parameters that are not registered services, the DI container fails.

Example:

public ProductService(IRepository repository, string connectionString)

Here, string connectionString is not registered as a service.

Solution:
Use IConfiguration or Options pattern instead of injecting primitive types directly.

Example fix:

public ProductService(IRepository repository, IConfiguration configuration)
{
var connectionString = configuration.GetConnectionString("Default");
}

6. Circular Dependency

If Service A depends on Service B and Service B depends on Service A, the DI container cannot resolve the dependency graph.

Example:
ServiceA → ServiceB
ServiceB → ServiceA

Solution:
Refactor architecture, introduce interfaces properly, or apply mediator pattern to break circular references.

7. Forgetting to Register External Services

When using external libraries such as AutoMapper, MediatR, FluentValidation, or custom middleware, their services must be registered.

Example:
builder.Services.AddAutoMapper(typeof(Program));

If not registered, injection will fail.

Real-World Scenario

Consider an enterprise e-commerce Web API project structured into:

• API Layer

• Application Layer

• Infrastructure Layer

If the Infrastructure layer contains the repository implementation but is not registered in the API layer’s DI container, controllers depending on repositories will fail during activation.

Correct approach:

builder.Services.AddInfrastructureServices();

And inside Infrastructure project:

public static IServiceCollection AddInfrastructureServices(this IServiceCollection services)
{
services.AddScoped<IProductRepository, ProductRepository>();
return services;
}

This ensures proper separation of concerns while resolving dependencies correctly.

Step-by-Step Troubleshooting Checklist

1. Verify the service is registered in Program.cs.

2. Confirm correct lifetime configuration.

3. Ensure correct interface-to-implementation mapping.

4. Check for circular dependencies.

5. Validate constructor parameters.

6. Confirm project references are added.

7. Rebuild the solution to refresh dependency graph.

Common Causes and Fixes Table

Cause	Why It Happens	How to Fix
Service not registered	Missing AddScoped/AddTransient/AddSingleton	Register service in DI container
Wrong lifetime	Singleton depends on Scoped	Align lifetimes properly
Missing implementation	Interface registered without concrete class	Provide implementation mapping
Circular dependency	Services depend on each other	Refactor architecture
Primitive type injection	DI cannot resolve raw types	Use IConfiguration or Options pattern
Namespace mismatch	Wrong interface reference	Verify correct project and namespace
External library not registered	Required services missing	Add required service registration

Advanced Debugging Techniques

Enable detailed logging to inspect DI behavior:

builder.Logging.SetMinimumLevel(LogLevel.Debug);

Use dependency validation during startup:

builder.Services.BuildServiceProvider(new ServiceProviderOptions
{
ValidateScopes = true,
ValidateOnBuild = true
});

This helps detect scope issues early in development.

Best Practices to Avoid This Error

• Follow clean architecture principles

• Group service registrations using extension methods

• Keep constructors minimal

• Avoid injecting primitive types

• Use the Options pattern for configuration

• Maintain consistent service lifetimes

• Write integration tests to validate DI setup

Summary

When the dependence Injection container is unable to create a necessary dependence because of missing registrations, wrong lifetimes, circular dependencies, or incorrectly set constructors, the "Unable to resolve service for type" error in.NET Core appears. Verifying service registration in the IServiceCollection, guaranteeing accurate interface-to-implementation mapping, coordinating service lifetimes, avoiding basic type injection, and upholding clear architectural boundaries are all necessary to resolve this problem. Developers may swiftly identify and resolve this frequent runtime problem in ASP.NET Core and distributed.NET applications by comprehending how the built-in DI container functions and using structured troubleshooting techniques.

Windows Hosting Recommendation

HostForLIFEASP.NET receives Spotlight standing advantage award for providing recommended, cheap and fast ecommerce Hosting including the latest Magento. From the leading technology company, Microsoft. All the servers are equipped with the newest Windows Server 2022 R2, SQL Server 2022, ASP.NET Core 10.0, ASP.NET MVC, Silverlight 5, WebMatrix and Visual Studio Lightswitch. Security and performance are at the core of their Magento hosting operations to confirm every website and/or application hosted on their servers is highly secured and performs at optimum level. mutually of the European ASP.NET hosting suppliers, HostForLIFE guarantees 99.9% uptime and fast loading speed. From €3.49/month , HostForLIFE provides you with unlimited disk space, unlimited domains, unlimited bandwidth,etc, for your website hosting needs.

 

Read More

SignalR vs. WebRTC: C# Real-Time Communication Architecture Choices

Real-time data interchange is a fundamental need for contemporary distributed systems, including IoT orchestration, live dashboards, telepresence, and collaborative apps. The two main technologies in the.NET ecosystem that facilitate low-latency interactions are SignalR and WebRTC; nevertheless, their goals, modes of transport, and network behaviors are very different. It is necessary to comprehend both the architectural implications and capabilities of each option in order to select the best one. 

Core Purpose & Communication Model

SignalR
A server-mediated pub/sub messaging framework called SignalR was created for the purpose of delivering events at the application level. Regardless of how close the client is, all data passes through the server hub. The abstraction automatically chooses between WebSockets, Server-Sent Events, and Long Polling, protecting developers from connection state management and transport negotiation. 

SignalR is ideal where:

• The server must enforce business governance over all traffic

• Events are lightweight and frequent (presence updates, notifications)

• Scaling uses horizontal hub instances backed by distributed messaging

Performance Characteristics

Dimension	SignalR	WebRTC
Latency	Low for events	Ultra-low for real-time media
Throughput	Optimized for small messages	Optimized for continuous streaming
Scaling Model	Server resource bound; hub fan-out	Client resource bound; mesh or SFU topology

SignalR introduces server compute and network amplification costs since every published event requires rebroadcast to subscribers. In contrast, WebRTC avoids hub amplification but requires sophisticated topology management — meshes degrade exponentially with participant counts, leading to SFU/MCU-based infrastructures.

Security & Governance

SignalR inherently centralizes control — identity, authorization, and auditing occur at the server boundary. Data visibility is total by design.

WebRTC enforces full DTLS-SRTP encryption between peers. However, distributed responsibility means:

• Authorization must occur before connection establishment

• E2E inspection is limited without a media terminator

• TURN servers may introduce compliance considerations when relaying payloads

Enterprise applications needing consistent regulatory enforcement typically lean toward SignalR unless an SFU layer is introduced as a controlled media authority.

Reliability & NAT Traversal

Feature	SignalR	WebRTC
Transport fallback	Automatic via ASP.NET pipeline	N/A — transport tuning is developer responsibility
NAT complexity	Minimal	High, especially in zero-trust networks
Server dependency	Required for all messages	Required only for signaling (and sometimes TURN relay)

WebRTC reliability hinges on the network’s openness to UDP and peer reachability. Environments such as healthcare, banking, and defense often severely restrict this, favoring the deterministic nature of SignalR.

Typical Use-Cases

Where SignalR excels

• Real-time UI synchronization (Blazor/SPA apps)

• Trading dashboards and telemetry readouts

• Multiplayer turn-based interactions

• Operational alerting and presence indicators

Where WebRTC excels

• Voice/video conferencing

• Live screen or sensor streaming

• Collaborative whiteboarding with high-frame-rate ink data

• AR/VR remote assistance

Hybrid Strategy: The Industry-Standard Answer for C# Architects

A common enterprise architecture uses:

• SignalR for signaling and metadata distribution

• WebRTC for media and high-frequency data channels

This yields centralized governance for session control while retaining peer-based transport for performance-critical flows. It is the same fundamental design underlying platforms like Teams, Zoom, and Web-based telepresence systems.

Recommendation Matrix

Requirement	Preferred Technology
Server must validate and inspect all content	SignalR
Low latency audio/video	WebRTC
High concurrency broadcasts	SignalR with distributed backplane
Minimal server bandwidth consumption	WebRTC
Strict firewall environments	SignalR
Future expansion to media streaming	Hybrid

Conclusion

• SignalR is a real-time event delivery abstraction centered on server authority.

• WebRTC is a peer-first streaming technology optimized for media and high-frequency data.

• Mature C# architectures often combine both, achieving governance + high performance.

Understanding these trade-offs ensures infrastructure cost optimization, regulatory alignment, and future scalability — the hallmarks of expert-level system design.

SignalR Hosting Recommendation

HostForLIFE.eu receives Spotlight standing advantage award for providing recommended, cheap and fast ecommerce Hosting including the latest SignalR. From the leading technology company, Microsoft. All the servers are equipped with the newest Windows Server 2022/2025, SQL Server 2022, ASP.NET Core 10.0, ASP.NET MVC, Silverlight 5, WebMatrix and Visual Studio Lightswitch. Security and performance are at the core of their Magento hosting operations to confirm every website and/or application hosted on their servers is highly secured and performs at optimum level. mutually of the European ASP.NET hosting suppliers, HostForLIFE guarantees 99.9% uptime and fast loading speed. From €3.49/month , HostForLIFE provides you with unlimited disk space, unlimited domains, unlimited bandwidth,etc, for your website hosting needs.

 

Read More

Which Version of .NET Should you Use at This Time?

One of the most crucial choices when beginning a new project is selecting the appropriate version of.NET. Developers frequently inquire:

• In 2026, which version of.NET should I use?
• Should I use STS or.NET LTS?
• Does the.NET Framework have any use today?

Based on Microsoft's support strategy and actual development scenarios, we'll address these questions in this post and assist you in selecting the.NET version you should use at this time.

Understanding .NET Versions: LTS vs STS

Microsoft releases a new version of .NET every year, following a predictable lifecycle.

What Is LTS (Long-Term Support)?

• Supported for 3 years

• Includes security patches and stability fixes

• Recommended for production and enterprise applications

What Is STS (Standard-Term Support)?

• Supported for 18 months

• Includes the latest runtime and language features

• Best for learning, experimentation, and short-term projects

SEO Tip: These terms are commonly searched, so explicitly defining them improves discoverability.

Latest .NET Versions You Can Use Today

.NET 8 (LTS) — Recommended for Most Applications

.NET 8 is the latest Long-Term Support version and the best choice for most developers.

Use .NET 8 if you are:

• Building a new production application

• Developing ASP.NET Core Web APIs

• Creating enterprise-level software

• Working on cloud-native or microservices-based systems

Key Benefits of .NET 8:

• Long-term Microsoft support

• Performance improvements

• Better container and cloud optimization

• Stable ecosystem and tooling

✔ SEO keywords naturally included:
.NET 8, .NET LTS, ASP.NET Core, enterprise application

.NET 9 (STS) — For Learning and Early Adoption

.NET 9 is a Standard-Term Support release focused on innovation.

Use .NET 9 if you:

• Want to explore new C# and runtime features

• Are building proof-of-concept (POC) applications

• Plan to upgrade frequently

Not recommended for long-term production systems due to its shorter support window.

.NET Framework — Only for Legacy Maintenance

.NET Framework is still used in older applications, but it is not suitable for new development.

Use only if:

• You are maintaining an existing legacy system

• Migration to modern .NET is not currently possible

❌ No cross-platform support ❌ No major feature updates

Which .NET Version Should You Choose? (Quick Guide)?

Project Type	Recommended .NET Version
New production app	.NET 8 (LTS)
Enterprise application	.NET 8 (LTS)
Learning C# and .NET	.NET 8 or .NET 9
Prototype / POC	.NET 9
Legacy app maintenance	.NET Framework

Final Recommendation

If you are starting a new project today, the answer is simple:

Use .NET 8 (LTS).

It provides the best balance of performance, stability, and long-term support, making it ideal for real-world applications.

Conclusion

Choosing the correct .NET version can save you significant time and effort in the future. While STS releases are exciting, LTS versions remain the safest choice for production environments.

Stay updated, but build smart.

Windows Hosting Recommendation

HostForLIFEASP.NET receives Spotlight standing advantage award for providing recommended, cheap and fast ecommerce Hosting including the latest Magento. From the leading technology company, Microsoft. All the servers are equipped with the newest Windows Server 2022 R2, SQL Server 2022, ASP.NET Core 7.0.10 , ASP.NET MVC, Silverlight 5, WebMatrix and Visual Studio Lightswitch. Security and performance are at the core of their Magento hosting operations to confirm every website and/or application hosted on their servers is highly secured and performs at optimum level. mutually of the European ASP.NET hosting suppliers, HostForLIFE guarantees 99.9% uptime and fast loading speed. From €3.49/month , HostForLIFE provides you with unlimited disk space, unlimited domains, unlimited bandwidth,etc, for your website hosting needs.

 

Read More

How to Manage Exceptions Worldwide in ASP.NET The core?

Regardless of size or volume, dependable exception management is essential to robust software. Critical data loss or system instability can result from poorly managed faults. Although ASP.NET Core provides a number of error management techniques, this article examines the Global Exception Handling method utilizing the IExceptionHandler interface. Cleaner code, a more manageable architecture, and consistent Problem Details (RFC 7807) replies are all ensured by centralizing error logic.

Methods for Handling Exceptions

Exceptions are specific objects in.NET that are used to indicate that a code execution error has occurred. The baseSystem is the source of all exceptions.class of exceptions. The program "throws" an exception object to alert the system when an issue occurs, like trying to access a missing file. Instead of just crashing, this method acts as an integrated alarm system, enabling the program to recognize and address problems. 

Several approaches of handling application faults are offered by ASP.NET Core:

• Conventional Try-Catch Blocks: The fundamental technique of enclosing particular code blocks to identify and fix local issues.
• Default Exception Middleware: Making use of built-in framework functions such as UseDeveloperExceptionPage and UseExceptionHandler.
• Developing specialized middleware components to detect and manage failures throughout the whole request lifecycle is known as custom exception middleware.
• IExceptionHandler (Best Practice): Introduced in.NET 8, this is the leading contemporary method. The recommended standard for putting in place a neat, organized, and centralized error-handling system is this interface.

Let's talk about each of the above. 

1. Standard Try-Catch Block

The try-catch block is the most common approach for immediate error handling. The following example demonstrates this implementation:

[HttpGet]
public IActionResult GetProducts()
{
    try
    {
        // Service call that may fail due to external factors
        var products = _productService.FetchAll();
        return Ok(products);
    }
    catch (Exception exception)
    {
        _logger.LogError(exception.Message);
        return StatusCode(StatusCodes.Status500InternalServerError);
    }
}

This reflects a standard pattern where the FetchAll() method represents a service or data call prone to errors. When an exception occurs, the catch block intercepts it to log the error details and return a 500 Internal Server Error status code. While functional, repeating this logic across every controller can quickly lead to redundant code.

If an error occurs while theGetProducts() method is running, the following exception is triggered:

throw new Exception("An error occurred while retrieving data.");

While this basic approach is straightforward, it significantly increases the total lines of code. While suitable for small Proof of Concept (POC) projects, manually inserting try-catch blocks into every controller action and service method is repetitive and difficult to maintain in larger systems.

A more effective strategy involves handling all exceptions in a single, central location. The following sections explore two approaches that improve the error-handling architecture by isolating all logic into a dedicated area. This results in a cleaner codebase and a more controlled application by removing the need for redundant error-handling code.

2. Exception Handling Middleware in .NET - UseExceptionHandler

To simplify development, ASP.NET Core provides the built-in ExceptionHandler Middleware. When configured in the Program.cs file, this middleware is added to the request pipeline to catch unhandled exceptions across the entire application. It offers a direct and efficient way to centralize error management.

The following example demonstrates how to configure the UseExceptionHandler middleware. Open the Program.cs file and apply the following configuration:

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
builder.Services.AddControllers();

var app = builder.Build();

// Configure the built-in exception handling middleware
app.UseExceptionHandler("/error-handler");

app.UseHttpsRedirection();
app.UseAuthorization();
app.MapControllers();

app.Run();

This configuration provides a foundational setup for the ExceptionHandler Middleware. Whenever the application pipeline detects an unhandled exception, execution control is automatically transferred to this middleware. It then intercepts the error and returns a customized response to the client, ensuring the application remains stable and provides informative feedback.

3. Custom Exceptions

It is both cleaner and more effective to categorize specific error types. This allows the application to respond uniquely to different failure scenarios later in the development process. Creating custom exception classes ensures that the application throws meaningful errors that are easier to diagnose.

To begin, create a new folder named Exceptions and add a class named ApplicationBaseException. This class must inherit from the baseException class. The implementation for this custom base exception is as follows:

namespace GlobalExceptionHandler.Domain.Exceptions
{
    public class GlobalAppException : Exception
    {
        public HttpStatusCode ResultStatusCode { get; }

        public GlobalAppException(string errorMessage, HttpStatusCode code = HttpStatusCode.InternalServerError)
            : base(errorMessage)
        {
            ResultStatusCode = code;
        }
    }
}

This GlobalAppException serves as the foundation for creating more specific error types. Inheriting from a shared base class is a cleaner architectural pattern for designing exception systems. For instance, a RecordNotFoundException can be created by inheriting from this base class.

public class RecordNotFoundException : GlobalAppException
{
    public RecordNotFoundException(Guid recordId)
        : base($"The record with ID {recordId} was not found.", HttpStatusCode.NotFound)
    {
    }
}

By using this approach, a service class can simply throw a RecordNotFoundException if a database or cache lookup fails. This provides immediate clarity in error logs regarding the nature of the issue and the specific identifier involved, eliminating the need to sift through complex stack traces.

The custom exception is utilized as follows:

throw new RecordNotFoundException(requestedProduct.Id);

4. Recommended exception handling in .NET 8: IExceptionHandler

Introduced in .NET 8, theIExceptionHandler interface is the current recommended standard for global error management. It is utilized internally by the framework and offers a more structured approach than traditional middleware.

The interface requires implementing a single method, TryHandleAsync, which processes the HTTP context and the specific exception. A major advantage is that it integrates directly with the existing UseExceptionHandler middleware, eliminating the need for a custom middleware class.

This approach allows for modular, maintainable code by enabling separate handling logic for different error types. The following example demonstrates how to implement IExceptionHandler:

The AppExceptionHandler class implements the IExceptionHandler interface to centralize error logic. The TryHandleAsync method processes the exception and returns true to signal that the error has been successfully handled. Returning false would allow the error to pass to the next handler in a chain.

public class AppExceptionHandler(ILogger<AppExceptionHandler> logger) : IExceptionHandler
{
    public async ValueTask<bool> TryHandleAsync(
        HttpContext context,
        Exception exception,
        CancellationToken cancellationToken)
    {
        var details = new ProblemDetails
        {
            Instance = context.Request.Path,
            Status = StatusCodes.Status500InternalServerError
        };

        if (exception is GlobalAppException appEx)
        {
            context.Response.StatusCode = (int)appEx.ResultStatusCode;
            details.Title = appEx.Message;
            details.Status = (int)appEx.ResultStatusCode;
        }
        else
        {
            details.Title = "An unexpected error occurred.";
        }

        logger.LogError(exception, "{ErrorTitle}", details.Title);

        await context.Response.WriteAsJsonAsync(details, cancellationToken);

        return true;
    }
}

To activate this handler, register it in Program.cs. This setup links the implementation with the built-in Problem Details services and the standard exception middleware.

builder.Services.AddExceptionHandler<AppExceptionHandler>();
builder.Services.AddProblemDetails();

// ... other configurations

var app = builder.Build();

app.UseExceptionHandler(); // Middleware to use the registered handlers

Conclusion

In this article we have seen various strategies for managing errors in ASP.NET Core. TheIExceptionHandler interface remains the recommended standard for modern applications, offering superior control and readability. Implementing this centralized approach ensures a cleaner, more maintainable, and resilient codebase. Hope you will find this useful.

Windows Hosting Recommendation

HostForLIFE.eu receives Spotlight standing advantage award for providing recommended, cheap and fast ecommerce Hosting including the latest Magento. From the leading technology company, Microsoft. All the servers are equipped with the newest Windows Server 2022 R2, SQL Server 2022, ASP.NET Core 10.0 , ASP.NET MVC, Silverlight 5, WebMatrix and Visual Studio Lightswitch. Security and performance are at the core of their Magento hosting operations to confirm every website and/or application hosted on their servers is highly secured and performs at optimum level. mutually of the European ASP.NET hosting suppliers, HostForLIFE guarantees 99.9% uptime and fast loading speed. From €3.49/month , HostForLIFE provides you with unlimited disk space, unlimited domains, unlimited bandwidth,etc, for your website hosting needs.

 

 

Read More

ASP.NET Tutorial: C# 14 and.NET 10: The Game Has Changed

An explanation of the significance of this release from a major engineer.

The Morning Everything Clicked

I recall seeing the.NET 10 preview builds for the first time. It was one of those infrequent software moments when you realize you're looking at a fundamental change in how we'll develop applications rather than an incremental upgrade.

In addition to being speedier and more aesthetically pleasing,.NET 10 was released in November 2025 as an LTS version with three years of support. It's leaner, smarter, and, to be honest, the most exciting.NET release I've seen in a long time. This is the reason.

Speed: Not Just Fast, Ridiculously Fast

The JIT Got a PhD in Optimization

The Just-In-Time compiler in .NET 10 does something fascinating. Instead of simply organizing your code blocks in order, it treats the problem like the Travelling Salesman Problem—finding the optimal path through your code to minimize cache misses and branch mispredictions.

Remember all those times you wrestled with struct performance? The JIT now places struct members directly into registers instead of bouncing them through memory. It's like going from passing notes through a mailbox to just handing them directly to someone.

And the inlining? It's gotten recursive. When the compiler inlines a method and realizes "hey, now I can devirtualize this other call," it does it. Then it checks again. It's optimization all the way down.

Memory That Actually Makes Sense

Stack allocation has been expanded dramatically. Small arrays, local delegates, even reference type arrays in some cases—they can now live on the stack instead of adding to garbage collection pressure. In one benchmark I ran, GC pauses dropped by 20%. Twenty percent. That's the difference between a smooth user experience and a janky one.

The garbage collector itself got smarter too, with dynamic write-barrier switching now available on ARM64. If you're shipping to mobile or Apple Silicon, this matters.

C# 14: Less Boilerplate, More Clarity
Extension Members: Finally!

This is the headline feature, and for good reason. We've had extension methods since C# 3.0, but they always felt incomplete. Now we have extension properties, operators, and static members.

public implicit extension PointExtensions for System.Drawing.Point
{
    public double Magnitude => Math.Sqrt(source.X * source.X + source.Y * source.Y);

    public static Point operator +(Point left, Point right)
        => new Point(left.X + right.X, left.Y + right.Y);
}

// Now you can write:
var magnitude = myPoint.Magnitude;  // Clean!
var sum = point1 + point2;          // Natural!

Third-party types suddenly feel like they were designed for your use case. It's beautiful.

Spans Become First-Class Citizens

If you've been writing high-performance .NET code, you know Span<T>. But you've probably also typed .AsSpan() about a thousand times. Not anymore.

void ProcessData(ReadOnlySpan<int> data) { /* ... */ }

int[] array = { 1, 2, 3, 4, 5 };
ProcessData(array);  // Just works now

Implicit conversions. Everywhere. Performance-critical code just got more readable.

The field Keyword: Small but Mighty

Ever started with an auto-property, then needed to add validation?

// Before: Create a backing field, convert the property...
private string _name;
public string Name
{
    get => _name;
    set => _name = value?.Trim() ?? string.Empty;
}

// Now:
public string Name
{
    get => field;
    set => field = value?.Trim() ?? string.Empty;
}

The compiler manages the backing field. You write less code. Everyone wins.

Null-Conditional Assignment

This one saves so much ceremony:

// Before
if (customer is not null)
{
    customer.TotalSpent += orderAmount;
}

// After
customer?.TotalSpent += orderAmount;

The right side only evaluates if the left side isn't null. It's the little things.

Other Gems

• nameof(List<>) - Works with unbound generics now

• Lambda parameter modifiers - (out int result) in lambdas? Yes.

• Partial constructors - Source generators rejoice

• User-defined compound assignment - Less operator overload duplication

The AI Revolution Arrives in .NET

Here's where things get wild. .NET 10 includes the Microsoft Agent Framework, and it's not just another library—it's a vision for how we'll build intelligent applications.

One Interface to Rule Them All

IChatClient client = new OpenAIChatClient(apiKey, "gpt-4");
// Or Azure OpenAI, or Ollama, or...

var response = await client.CompleteAsync("Explain quantum computing");

Switch AI providers? Change one line. The abstraction is clean, the middleware is built-in, and the telemetry just works.

Model Context Protocol (MCP)

This is the secret sauce. MCP servers let your AI agents securely access external systems—databases, APIs, internal tools—without you having to wire up authentication and authorization from scratch.

You can even publish MCP servers as NuGet packages. Build once, reuse everywhere. The AI agent ecosystem just became composable.

dotnet new mcp-server -n MyCompanyDataAccess

The Supporting Cast

Post-Quantum Cryptography

Quantum computers are coming. .NET 10 is ready with ML-DSA, ML-KEM, and SLH-DSA algorithms. Your encrypted data won't become readable in 2030 when quantum computers arrive at scale.

WebSocketStream

Traditional WebSocket APIs are verbose. The new WebSocketStream wraps everything in a familiar Stream interface:

var stream = new WebSocketStream(ws, ownsWebSocket: true);
await stream.WriteAsync(data, cancellationToken);

No more manual buffer management. Just streams.

Async ZIP Operations

Finally. Creating and extracting ZIP files without blocking your UI thread:

var archive = await ZipArchive.CreateAsync(stream, ZipArchiveMode.Create);
var entry = await archive.CreateEntryAsync("data.txt");
await using var entryStream = await entry.OpenAsync();

JSON Improvements

Stricter serialization options, better throughput, PipeReader support. If you're building APIs, you'll notice the difference.

Framework Updates That Matter

ASP.NET Core 10

Blazor preloads WebAssembly components now, making initial loads noticeably faster. Passkey support in Identity means you can finally build passwordless auth properly. OpenAPI 3.1 generates better documentation with full JSON Schema 2020-12 support.

.NET MAUI

Multiple file selection in MediaPicker, WebView request interception, and Android API 35/36 support. Cross-platform development keeps getting smoother.

Entity Framework Core 10

Named query filters let you have multiple filters per entity and disable them selectively. The LINQ translator handles more complex queries. Performance optimizations make everything faster.

Real-World Impact

I refactored a text parsing service after upgrading to .NET 10. Changed maybe twenty lines to use new C# 14 features. Performance improved by 23%. GC pauses dropped by 15%. The code is cleaner. This isn't hype—it's measurable.

Should You Upgrade?

If you're starting a new project, absolutely. LTS support means you're covered for three years.

If you have existing apps, yes, but plan it. Most code just works, but the new span conversions might change overload resolution in edge cases. Test thoroughly.

If you're building AI-powered applications, this is your moment. The Agent Framework gives you a three-year head start.

The Bottom Line

.NET 10 and C# 14 represent something special a platform that's both mature and forward-thinking. The runtime is faster. The language is cleaner. AI integration isn't bolted on; it's built in.

Microsoft isn't just keeping up with modern development trends. With this release, they're setting them.

After twenty years of .NET evolution, watching it embrace AI-first development while maintaining backward compatibility and improving performance is remarkable. This is what great platform engineering looks like.

Time to upgrade. You won't regret it.

Windows Hosting Recommendation

HostForLIFEASP.NET receives Spotlight standing advantage award for providing recommended, cheap and fast ecommerce Hosting including the latest Magento. From the leading technology company, Microsoft. All the servers are equipped with the newest Windows Server 2022 R2, SQL Server 2022, ASP.NET Core 7.0.10 , ASP.NET MVC, Silverlight 5, WebMatrix and Visual Studio Lightswitch. Security and performance are at the core of their Magento hosting operations to confirm every website and/or application hosted on their servers is highly secured and performs at optimum level. mutually of the European ASP.NET hosting suppliers, HostForLIFE guarantees 99.9% uptime and fast loading speed. From €3.49/month , HostForLIFE provides you with unlimited disk space, unlimited domains, unlimited bandwidth,etc, for your website hosting needs.

 

Read More

Comprehending QuickEHow to Quit Wasting Resources: An Introduction to .NET CancellationTokensndpoints in .NET

It is frequently necessary to stop an activity before it finishes in contemporary.NET Core applications, particularly those that include long-running activities, asynchronous actions, or HTTP requests. The CancellationToken is useful in this situation.

This article will explain what CancellationToken is, why it's necessary, how it functions, and how to use it using a basic example.

What is a CancellationToken?

A CancellationToken in .NET Core is a mechanism to signal that an operation should be canceled. It allows tasks, loops, or asynchronous operations to cooperatively stop execution when requested.

Think of it as a “stop sign” you can pass to an operation. The operation checks this token periodically, and stops gracefully if cancellation is requested.

Why Do We Need CancellationToken?

Imagine a scenario where your application is performing a long-running task, like:

• Downloading a large file

• Processing millions of records

• Calling an external API that might hang

Without a cancellation mechanism:

• The operation will run until completion, wasting resources.

• Users cannot stop operations if they change their mind.

• It could lead to unresponsive applications.

CancellationToken solves this by allowing controlled, cooperative cancellation.

Key Components

1. CancellationTokenSource (CTS)

   • Generates a CancellationToken.

   • Signals when cancellation is requested.

2. CancellationToken

   • Passed to the task or method that needs to support cancellation.

   • Checked periodically to stop execution.

How to Use CancellationToken?

Step 1: Create a CancellationTokenSource

var cts = new CancellationTokenSource();
CancellationToken token = cts.Token;

Step 2: Pass the Token to an Operation

async Task DoWorkAsync(CancellationToken cancellationToken)
{
    for (int i = 0; i < 10; i++)
    {
        // Check if cancellation has been requested
        if (cancellationToken.IsCancellationRequested)
        {
            Console.WriteLine("Operation canceled!");
            return;
        }

        Console.WriteLine($"Working... {i + 1}");
        await Task.Delay(1000); // Simulate work
    }

    Console.WriteLine("Work completed successfully!");
}

Step 3: Request Cancellation

// Start the task
var task = DoWorkAsync(token);

// Cancel after 3 seconds
cts.CancelAfter(3000);

await task;

Output:

Working... 1
Working... 2
Working... 3
Operation canceled!

Notice how the task stops gracefully when cancellation is requested.

Use Cases for CancellationToken

1. HTTP Requests
   Cancel an API call if it takes too long or the client disconnects.

2. Background Services
   Stop background tasks in ASP.NET Core when the application shuts down.

3. Long-Running Operations
   Allow users to cancel processes like file uploads, downloads, or heavy calculations.

Best Practices

1. Always check IsCancellationRequested
   Inside loops or long operations.

2. Throw OperationCanceledException for Tasks

   • In tasks, you can throw OperationCanceledException when canceled.

   • This ensures proper task cancellation and status handling.

cancellationToken.ThrowIfCancellationRequested();

3. Pass the token to async methods that support it
   Many .NET Core methods like Task.Delay or HttpClient.SendAsync accept CancellationToken.

4. Dispose CancellationTokenSource
   After use, dispose to free resources:

cts.Dispose();

Real-World Example: Cancel HTTP Request

using var cts = new CancellationTokenSource();
var client = new HttpClient();

try
{
    cts.CancelAfter(2000); // cancel after 2 seconds
    HttpResponseMessage response = await client.GetAsync("https://example.com/largefile", cts.Token);
    string content = await response.Content.ReadAsStringAsync();
    Console.WriteLine(content);
}
catch (OperationCanceledException)
{
    Console.WriteLine("HTTP request was canceled.");
}

This pattern is especially useful in web applications where users may navigate away or abort a request.

Advantages

Advantage
Graceful Cancellation	Tasks stop safely without leaving the system in an inconsistent state.
Better Resource Management	Prevent unnecessary CPU, memory, or network usage.
Improved User Experience	Users can cancel long-running operations instead of waiting.
Integrates with Async/Await	Works seamlessly with modern asynchronous programming patterns.

Conclusion

We've seen how CancellationToken is a potent and crucial tool for.NET Core developers in this article. It enables you to regulate execution, effectively manage resources, and enhance user experience whether you are creating long-running activities, background services, or API calls.

You may create software that is professional-grade, robust, and responsive by understanding how to use CancellationToken. I hope this is useful to you. Enjoy your reading!

Windows Hosting Recommendation

HostForLIFE.eu receives Spotlight standing advantage award for providing recommended, cheap and fast ecommerce Hosting including the latest Magento. From the leading technology company, Microsoft. All the servers are equipped with the newest Windows Server 2022 R2, SQL Server 2022, ASP.NET Core 10.0 , ASP.NET MVC, Silverlight 5, WebMatrix and Visual Studio Lightswitch. Security and performance are at the core of their Magento hosting operations to confirm every website and/or application hosted on their servers is highly secured and performs at optimum level. mutually of the European ASP.NET hosting suppliers, HostForLIFE guarantees 99.9% uptime and fast loading speed. From €3.49/month , HostForLIFE provides you with unlimited disk space, unlimited domains, unlimited bandwidth,etc, for your website hosting needs.

 

Read More