DEV Community: FakeStandard

Fetch API — Understanding Request.cache

FakeStandard — Mon, 24 Nov 2025 06:57:19 +0000

When a webpage sends a request, it usually uses HTTP Cache. The Request.cache property in the Fetch API lets you tell the browser how it should handle caching for that particular request.

Before diving in, let's quickly clarify two common cache terms you need to know:

Fresh – The cached resource is still valid; the browser can safely use it without checking the server.
Stale – The cache is expired or potentially outdated; the browser might need to revalidate it with the server before using it. These two concepts are the foundation of how HTTP caching decides whether to use or refresh stored data.

Okay, let's break down how each cache mode works.

🔍 The Six Cache Modes

The Fetch API supports six different cache modes you can set:

type RequestCache = "default" | "force-cache" | "no-cache" | "no-store" | "only-if-cached" | "reload";

default
Uses the browser's default cache behavior.

If there's no cached resource, it'll fetch it from the server.
If the cache exists and hasn't expired, it'll use it directly.
If the cache exists but is expired, the browser sends a conditional request to check with the server — if the resource hasn't changed, it reuses the cache; otherwise, it downloads the new resource and updates the cache.

no-store
Always fetches from the server without reading or writing to the cache. Basically, every request is a fresh one.

reload
Doesn't use the cache at all — always fetches from the server, but once it gets the resource, it updates the cache with it.

no-cache
Pretty similar to default, but with one key difference:
Even if a cache exists (whether is fresh or stale), it still sends a request to the server to check if the resource has changed.

If it hasn't, it uses the cached version
If it has, it fetches the new one and stores it in the cache
If there's no cache at all, it just fetches from the server.

force-cache
Always tries to use the cached version first. Only if there's no matching cache entry will it make a network request and then store the new response in the cache.

only-if-cached
Only serves from the cache — no network request at all. If the cache doesn't have the resource, the request fails with HTTP 504 (Gateway timeout).
Note: only-if-cached only works when mode is set to same-origin

🧩 Choosing the Right Cache Mode (Examples)

Imagine you're building a dashboard that shows real-time stock prices. You definitely don't want stale data, so you'd go with:

fetch(url, { cache: 'no-store' })

This ensures every request hits the server and gets the latest prices, no cache involved.

But for something like a user profile photo or a static JSON config, you don't need to fetch it every single time. In that case, using force-cache or even the default mode works better:

fetch(url, { cache: 'force-cache' })

That way, the browser loads it instantly from cache if it's already available, and only fetches again when necessary — faster and more efficient.

🍺 Wrapping Up

Use no-store when you always need the newest data.
Use force-cache or default for static assets or infrequently updated content.
Use no-cache when you want freshness but still leverage conditional requests.
Use reload to refresh your cache with the latest version.
Use only-if-cached only if you want offline-only behavior.

Easy fix. Job done ☑️

Thanks for reading!

If you like this article, please don't hesitate to click the heart button ❤️
or follow my GitHub I'd appreciate it.

Understanding HTTP Content-Type

FakeStandard — Thu, 13 Nov 2025 02:43:01 +0000

The HTTP Content-Type header tells the server or browser what kind of data is begin sent and how it's encoded. Setting the correct Content-Type makes sure both the client and server understand each other — it also helps the browser handle data safely and efficiently.

When a client (like your browser or app) sends a request, it should include a Content-Type so the server knows how to read the data. Likewise, when the server sends a response back, it should also specify the Content-Type so the client knows how to process or display it.

🔅 The Structure of Content-Type

A Content-Type header is made up of a MIME type and (optionally) a charset for encoding

Content-Type: <mime-type>[; charset=<encoding>]

Example

Content-Type: text/html; charset=utf-8

text/html — MIME type
charset=utf8 — character encoding

When the browser receives a response with Content-Type: text/html, it knows to render it as an HTML page.
If it's image/jpeg, the browser knows it's an image and display it instead.

🔍 What’s a MIME Type?

A MIME type is a standardized way to describe different types of data on the web. You can find the full official list here IANA Media Types

Common Content-Type Values in Web Development

Content-Type	Description
`text/html`	HTML document
`text/plain`	Plain text
`text/xml`	XML data
`image/gif`	GIF image
`image/jpeg`	JPEG image
`image/png`	PNG image
`application/json`	JSON data
`application/pdf`	PDF document
`application/msword`	Word document
`application/octet-stream`	Binary data
`application/x-www-form-urlencoded`	Default format for HTML forms
`multipart/form-data`	Used for file uploads

🍵 Setting Headers with Fetch API

When you send data using Fetch API, you can set the Content-Type in the request headers.
Here's a simple example of sending JSON data to server

fetch(url, {
    method: 'POST',
    body: JSON.stringify(data),
    headers: {
        'content-type': 'application/json',
    }
})
    .then((res) => res.json())
    .then((response) => console.log("Success:", response))
    .catch((error) => console.error("Error:", error));

We convert data to JSON before sending (JSON.stringify())
The header Content-Type: 'application/json' tells the server we're sending JSON
The server can then parse it properly using a JSON parser.

Easy fix. Job done ☑️

Thanks for reading!

If you like this article, please don't hesitate to click the heart button ❤️
or follow my GitHub I'd appreciate it.

Using the Fetch API

FakeStandard — Fri, 07 Nov 2025 02:48:36 +0000

Back in the day, we used XMLHttpRequest to call APIs.
Nowadays, we use the Fetch API instead — it gives us a JavaScript Interface to handle HTTP request more cleanly.

Let's take a look at how to use it.

🔍 Basic Fetch Request

Here's the basic flow:

Specify the URL you want to call.
The first then gets a promise — you use response.json() to parse the response as JSON.
The second then handles the parsed JSON data.
If the fetch runs into an error that's not a 4xx or 5xx response, the catch block will handle it.

fetch("http://example.com/movies.json")
    .then(response => {
        return response.json();
    })
    .then(json => {
        console.log(json);
    })
    .catch(error => {
        console.error(error);
    });

If the server responds with JSON, you'll need to call response.json() to parse and return it as JSON.
If it returns a different format, you'll have to use another method to handle it.
Here are the five ways to parse a response:

arrayBuffer()
blob()
formData()
json()
text()

🌰 Request Configuration

Fetch takes a second parameter called RequestInit, which lets you configure the request that things like the HTTP method, headers, body, and so on.

fetch(url, {
    method: 'POST',
    body: JSON.stringify(data),
    headers: {
        'content-type': 'application/json',
    },
    cache: 'no-cache',
    credentials: 'same-origin',
    mode: 'cors',
})
    .then(response => {
        return response.json();
    })
    .then(json => {
        console.log(json);
    })
    .catch(error => {
        console.error(error);
    });

Here are some of the most common options:

method — HTTP request method, like GET, POST, PUT, DELETE, etc.
body — The data you want to send to the server.
headers — Lets you set custom request headers.
cache — Tells the browser how to handle HTTP caching for this request.
credentials — Controls whether cookies or credentials are sent with the request.
mode — Defines how to handle cross-origin requests.

Here's the full RequestInit interface definition for reference:

interface RequestInit {
    /** A BodyInit object or null to set request's body. */
    body?: BodyInit | null;
    /** A string indicating how the request will interact with the browser's cache to set request's cache. */
    cache?: RequestCache;
    /** A string indicating whether credentials will be sent with the request always, never, or only when sent to a same-origin URL. Sets request's credentials. */
    credentials?: RequestCredentials;
    /** A Headers object, an object literal, or an array of two-item arrays to set request's headers. */
    headers?: HeadersInit;
    /** A cryptographic hash of the resource to be fetched by request. Sets request's integrity. */
    integrity?: string;
    /** A boolean to set request's keepalive. */
    keepalive?: boolean;
    /** A string to set request's method. */
    method?: string;
    /** A string to indicate whether the request will use CORS, or will be restricted to same-origin URLs. Sets request's mode. */
    mode?: RequestMode;
    /** A string indicating whether request follows redirects, results in an error upon encountering a redirect, or returns the redirect (in an opaque fashion). Sets request's redirect. */
    redirect?: RequestRedirect;
    /** A string whose value is a same-origin URL, "about:client", or the empty string, to set request's referrer. */
    referrer?: string;
    /** A referrer policy to set request's referrerPolicy. */
    referrerPolicy?: ReferrerPolicy;
    /** An AbortSignal to set request's signal. */
    signal?: AbortSignal | null;
    /** Can only be null. Used to disassociate request from any Window. */
    window?: null;
}

You can adjust these settings depending on what your request needs.

🧩 Example

Here are a few simple examples.

Get request with query parameters

const params = new URLSearchParams();
params.append("id", "1")

const res = await fetch(`${url}?${params}`)

POST request with JSON data

fetch(url, {
    method: 'POST',
    body: JSON.stringify(data),
    headers: {
        'content-type': 'application/json',
    }
})
    .then((res) => res.json())
    .then((response) => console.log("Success:", response))
    .catch((error) => console.error("Error:", error));

Uploading a file

var formData = new FormData()
var fileField = document.querySelector("input[type='file']")

formData.append("file", fileField.files[0])

fetch(url, {
    method: 'PUT',
    body: formData
})
    .then((response) => response.json())
    .then((response) => console.log("Success:", response))
    .catch((error) => console.error("Error:", error))

🍺 Wrapping Up

The Fetch API is modern, promise-based, and a lot cleaner than XMLHttpRequest.
Once you get used to it, making HTTP requests in JavaScript becomes way simpler, easier to read, and more maintainable.

Easy fix. Job done ☑️

Thanks for reading!

If you like this article, please don't hesitate to click the heart button ❤️
or follow my GitHub I'd appreciate it.

A Practical Guide to .NET Automatic Memory Management

FakeStandard — Fri, 31 Oct 2025 03:58:20 +0000

What these terms actually mean

Automatic Memory Management
Allocating Memory
Releasing Memory
Generations and Performance

🔍 Automatic Memory Management

During managed execution, the CLR provides a service called automatic memory management, which takes care of allocating and releasing memory for your application. This means developers don't need to write manual memory management code anymore.

It also prevents two of the most common mistakes in manual memory handling

Forgetting to free unused objects, which leads to memory leaks
Trying to access memory that has already been released

🔅 Allocating Memory

When a process starts, the runtime reserves a continuous block of memory address space for it, known as the Managed Heap. The starting point of this heap is called the Base Address, and the runtime keeps a pointer there to indicate where new memory can be allocated.

When your application creates its first reference type, it's placed right at the Base Address of the Managed Heap. The next object goes right after it, and so on. As long as there's enough address space, new objects are laid out one after another. Once the space runs out, the Garbage Collector (GC) kicks in to release memory.

🔋 Releasing Memory

Every application has a set of roots, which reference objects on the Managed Heap or are set to null. An application's roots include static fields, local variables and parameters on a thread's stack, CPU registers, GC handles, and the finalize queue.

When the GC runs, it:

Checks which objects on the Managed Heap are still referenced by the application's roots
Finds the objects that are no longer in use
Frees the memory occupied by unused objects, and compacts the remaining ones to make memory contiguous again
Updates all pointers so that the roots now reference the objects at their new addresses

The GC's optimization engine decides when it's the best time to collect, based on system state and memory usage. When it runs, it identifies objects that are no longer used and reclaims their memory space.

🌀 Generations and Performance

In .NET, the Managed Heap is divided into three generations to improve performance

Generation 0
Generation 1
Generation 2

When new objects are created, they're first placed in Generation 0. As the app runs, objects that survive multiple garbage collections are promoted to Generation 1 and eventually Generation 2.

Initially, new objects go into Gen 0. When Gen 0 runs out of space, the GC runs a collection, freeing memory from objects that are no longer used. If an object survives multiple collections, it gets promoted to Gen 1 — basically meaning it has a longer lifetime. If after collecting Gen 0, there's still not enough free memory, the GC will continue with Gen 1 or Gen 2 collections.

The .NET GC is based on the assumption that most objects are short-lived. Scanning the entire Managed Heap every time would be too expensive, it would mean moving and rearranging everything constantly. That's why the GC divides the heap into generations, it can focus on newer objects first and only move on to older generations when necessary. This keeps memory management efficient without constantly touching every object.

💡 Key Points

The CLR's automatic memory management frees developers from handling memory manually and helps prevent memory leaks and invalid reference.
The runtime allocates objects continuously on the Managed Heap, when space runs out, the GC reclaims memory from unused objects.
The GC scans the application's roots, identifies unreferenced objects, releases them, compacts surviving ones, and updates references to reduce fragmentation.
The GC divides objects into three generations — Gen 0, Gen 1, Gen 2 — based on their lifetime.
It prioritizes collecting Gen 0 objects and only scans older generations when needed, reducing unnecessary object movement.

Easy, right? Job done ☑️

Thanks for reading!

If you like this article, please don't hesitate to click the heart button ❤️
or follow my GitHub I'd appreciate it.

A Practical Guide to .NET CLR, Managed and Unmanaged Code, and Interop

FakeStandard — Tue, 21 Oct 2025 05:22:59 +0000

What these terms actually mean

Common Language Runtime (CLR)
Managed Code
Unmanaged Code
Interoperability (Interop)

🔥 Common Language Runtime (CLR)

The Common Language Runtime (CLR) is basically the core engine of the .NET environment. It takes care of memory management, threading, code security checks, compilation, and execution — plus a bunch of system-level services like automatic memory management, security boundaries, type safety, and just-in-time (JIT) compilation. All these features are built right into the managed code that runs on top of the CLR.

In other words, your C# program doesn't run directly on the operating system — it runs on the CLR.

📗 What Is Managed Code

Managed code is code that runs under the supervision of the CLR. It can be written in any .NET supported language — C#, F#, VB, and so on. When you compile your source code, it doesn't go straight to machine code; instead, it becomes something called Intermediate Language (IL), stored in .dll or .exe files.

When you launch your .NET app, the CLR loads the IL and uses the Just-In-Time (JIT) compiler to turn it into machine code on the fly — code that your CPU can actually run.

So, the CLR doesn't execute your C# code directly. The compiler first translates your high-level code into IL, and then the CLR steps in to convert that IL into machine code via JIT. That's how the CLR understands what your program does and manages it efficiently.

📘 What Is Unmanaged Code

Languages like C and C++ produce unmanaged code, meaning the operating system reads and executes their binary instructions directly from memory. This also means developers need to handle everything themselves — from memory allocation to cleanup and deal with all the safety considerations manually.

As a C# developer, you don't have to worry about most of that, because the CLR takes care of memory management automatically.

📚 Interoperability (Interop)

The CLR also allows managed and unmanaged code to work together. That means your managed code can call into unmanaged code, such as a COM component or a native DLL.

When that happens, your code crosses the CLR boundary — a process called Interoperability, or simply Interop. Once the code leaves the CLR boundary, it doesn't magically become managed; you still have to handle memory and safety on your own.

Interop is everywhere — even the .NET Class Library uses it internally for things like file I/O, windows, network connections, and database access.

🍺 Wrapping Up

Here's a diagram from the official .NET documentation that shows how the CLR, Class Library, and your application interact with the underlying system, and how managed and unmanaged code fit into the picture.

It took me quite a while to really grasp this. The first time I read the docs, I barely understood a word. But after going through them several times and checking different resources, things started to click. Hopefully, this explanation makes it easier for you too.

Easy, right? Job done ☑️

Thanks for reading!

If you like this article, please don't hesitate to click the heart button ❤️
or follow my GitHub I'd appreciate it.

Exploring .NET Dependency Injection Lifetimes with Real Examples

FakeStandard — Fri, 10 Oct 2025 09:00:56 +0000

When we register services in the DI (Dependency Injection) container in .NET, the service instance has an important concept called Lifetime, it tells the system when the service is created, shared, and disposed.

📌 What is Service Lifetime

.NET provides three types of service lifetimes

Singleton
Scoped
Transient

Here's a quick look at what they mean behind the scenes

namespace Microsoft.Extensions.DependencyInjection
{
    public enum ServiceLifetime
    {
        Singleton = 0, // One instance for the entire app lifetime
        Scoped = 1, // One instance per scope (typically per request)
        Transient = 2  // A new instance every time it's requested
    }
}

Singleton
The instance is created on the first request, and then it just sticks around. No matter how many requests come in after that, it will keep using that one instance throughout the app's lifetime.

Scoped
In a web app, a new instance is created per client or per request scoped. So inside the same browser session, you get the same instance. But across different clients or browsers, each gets its own instance.

Transient
A new instance is created every time it's requested. Once the request ends, that instance is gone.

🍵 How to Test

Since testing in a Console App can only really show the difference between Singleton and Transient, we'll use a Web App to demonstrate all three lifetimes.

We first create the Operation class and interface, and define interfaces that represent the three different lifetimes, all inheriting from IOperation.

public class Operation : IOperationTransient, IOperationScoped, IOperationSingleton
{
    public string OperationId { get; }
    public Operation()
    {
        OperationId = Guid.NewGuid().ToString()[^4..];
    }
}
public interface IOperation
{
    string OperationId { get; }
}

public interface IOperationTransient : IOperation { }
public interface IOperationScoped : IOperation { }
public interface IOperationSingleton : IOperation { }

Next, register the services with different lifetimes in Program.cs.

var builder = WebApplication.CreateBuilder(args);

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

// Add services to the container with lifetime
builder.Services.AddTransient<IOperationTransient, Operation>();
builder.Services.AddScoped<IOperationScoped, Operation>();
builder.Services.AddSingleton<IOperationSingleton, Operation>();

Inject the three service instances into HomeController.cs.

public class HomeController(ILogger<HomeController> logger,
    IOperationSingleton singleton,
    IOperationScoped scoped,
    IOperationTransient transient) : Controller
{
    private readonly ILogger<HomeController> _logger = logger;

    private readonly IOperationSingleton _singleton = singleton;
    private readonly IOperationScoped _scoped = scoped;
    private readonly IOperationTransient _transient = transient;

    // ...
}

In the Index action, get the OperationId of each instance and store them in the ViewBag.

public IActionResult Index()
{
    ViewBag.Singleton = _singleton.OperationId;
    ViewBag.Scoped = _scoped.OperationId;
    ViewBag.Transient = _transient.OperationId;

    return View();
}

Then in index.cshtml, retrieve the values from the ViewBag.

<table class="table">
    <thead>
        <tr>
            <td>Service Lifetime</td>
            <td>OperationId</td>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td>Singleton</td>
            <td>@ViewBag.Singleton</td>
        </tr>
        <tr>
            <td>Scoped</td>
            <td>@ViewBag.Scoped</td>
        </tr>
        <tr>
            <td>Transient</td>
            <td>@ViewBag.Transient</td>
        </tr>
    </tbody>
</table>

Finally, run the app, open it in three different browsers, and observe the differences in the OperationId values.

In all three browsers, the OperationId for the Singleton service remains the same. Refreshing the page or opening a new browser window doesn't change it. This confirms that the Singleton instance is created during the first request and reused throughout the app's lifetime.

At this point, there's no visible difference between Scoped and Transient. To help observe their differences, we modify the code to inject two instances of each service.

public class HomeController(ILogger<HomeController> logger,
    IOperationSingleton singleton,
    IOperationScoped scoped,
    IOperationTransient transient,
    IOperationSingleton singleton2, // second instance
    IOperationScoped scoped2, // second instance
    IOperationTransient transient2 // second instance
    ) : Controller
{
    private readonly ILogger<HomeController> _logger = logger;

    private readonly IOperationSingleton _singleton = singleton;
    private readonly IOperationScoped _scoped = scoped;
    private readonly IOperationTransient _transient = transient;

    private readonly IOperationSingleton _singleton2 = singleton2;
    private readonly IOperationScoped _scoped2 = scoped2;
    private readonly IOperationTransient _transient2 = transient2;

    public IActionResult Index()
    {
        ViewBag.Singleton = _singleton.OperationId;
        ViewBag.Scoped = _scoped.OperationId;
        ViewBag.Transient = _transient.OperationId;

        ViewBag.Singleton2 = _singleton2.OperationId;
        ViewBag.Scoped2 = _scoped2.OperationId;
        ViewBag.Transient2 = _transient2.OperationId;

        return View();
    }
}

And modify tbody tag.

<tbody>
    <tr>
        <td>Singleton</td>
        <td>@ViewBag.Singleton</td>
        <td>@ViewBag.Singleton2</td>
    </tr>
    <tr>
        <td>Scoped</td>
        <td>@ViewBag.Scoped</td>
        <td>@ViewBag.Scoped2</td>
    </tr>
    <tr>
        <td>Transient</td>
        <td>@ViewBag.Transient</td>
        <td>@ViewBag.Transient2</td>
    </tr>
</tbody>

Now, we can observe that the OperationId of Transient services is always different—meaning a new instance is created on every request and disposed of afterwards.

Meanwhile, the Scoped service has the same OperationId within the same browser session, but different values in different browsers. This confirms that each client request uses a different instance, but within a single client, the same instance is reused across multiple requests.

💡 Key points

Singleton — stays the same instance everywhere.
Scoped — has the same instance within the same browser (client), no matter how many times you call it or inject it. But across different browsers (clients), it's different. So it shares the instance per client/request.
Transient — gives you a different OperationId every single time, even when injected twice in the same request. it's always a new instance, and it's disposed of once the request is done.

🔎 When to use each lifetime？

Singleton
Use it for — Stateless, heavy-to-create services, global settings, caching, or long-running resources.
Examples: Configuration, Logger, Memory Cache, Queue, Timer.
⚠️ Don't depend on Scoped or Transient services inside a Singleton, it may cause weird bugs.

Scoped
Use it for — Sharing data during a request, DB connection scoped, or objects tied to business logic.
Examples: Repositories, Unit of Work, session-based cache, request-level state tracking.
⚠️ Avoid injecting Singleton services into Scoped ones.

Transient
Use it for — Lightweight, stateless services that don't need to share data.
Examples: Validators, Calculators, Formatters, Utility Classes.
⚠️ Overusing Transient can lead to too many objects and unnecessary GC pressure.

🍺 Wrapping Up

Now that you understand how service lifetimes work, you'll have a much better sense of how to register services properly and manage resources effectively.

Easy, right? Job done ☑️

Thanks for reading!

If you like this article, please don't hesitate to click the heart button ❤️
or follow my GitHub I'd appreciate it.

Create a Custom Middleware in .NET

FakeStandard — Sat, 04 Oct 2025 05:45:41 +0000

Creating custom middleware in .NET is straightforward and powerful. Here's a quick step-by-step guide to help you build and register your own middleware.

First, create a folder named Middlewares to store all your custom middleware classes. Inside this folder, create a middleware called RequestIPMiddleware which is encapsulated in a class. This middleware logs the user's IP address to the console.

Here's an example.

public class RequestIPMiddleware
{
    private readonly RequestDelegate _next;
    private readonly ILogger _logger;

    public RequestIPMiddleware(RequestDelegate next, ILoggerFactory loggerFactory)
    {
        _next = next;
        _logger = loggerFactory.CreateLogger<RequestIPMiddleware>();
    }

    public async Task Invoke(HttpContext context)
    {
        _logger.LogInformation($"User IP: {context.Connection.RemoteIpAddress}");

        await _next.Invoke(context);
    }
}

Second, create an Extensions folder to store your middleware extension methods. Inside it, add a new static class called RequestIPExtension. This extension method allows you to easily register the middleware in your application.

public static class RequestIPExtension
{
    public static IApplicationBuilder UseRequestIP(this IApplicationBuilder builder)
    {
        return builder.UseMiddleware<RequestIPMiddleware>();
    }
}

Third, open your Program.cs file and register the custom middleware, which is exposed via an extension method, like this:

var app = builder.Build();

// your custom middleware
app.UseRequestIP();
app.UseStaticFiles();

Run your application, and you should see the user's IP address logged in the console.

If your middleware is simple and you don't want to create a separate class or extension method, you can also define an inline middleware directly in Program.cs, like this:

app.Use(async (context, next) =>
{
    var logger = context.RequestServices.GetRequiredService<ILoggerFactory>().CreateLogger("RequestIPLogger");
    logger.LogInformation($"User IP: {context.Connection.RemoteIpAddress}");

    await next(context);
});

Easy, right? Job done ☑️

Thanks for reading!

If you like this article, please don't hesitate to click the heart button ❤️
or follow my GitHub I'd appreciate it.

Simplifying Graph API Authentication with C#

FakeStandard — Thu, 25 Sep 2025 10:14:53 +0000

When I was working with Azure.Identity.ClientSecretCredential for authentication, I noticed something interesting—it doesn't require me to manually grab a access token and add it to the header. The ClientSecretCredential takes care of fetching the token for me. Pretty cool, right?

Here's how it works in code

using Azure.Identity;
using Microsoft.Graph;

// Use ClientSecretCredential for authentication
var credential = new ClientSecretCredential(tenantId, clientId, clientSecret);

// Create a GraphServiceClient instance
var graphClient = new GraphServiceClient(credential);

// Make the API call
var users = await graphClient.Users.GetAsync();

Now, if you were to use MSAL to get the token and then manually call the Graph API with HttpClient, it would be a bit more complex and the data you'd get back would be in raw JSON format. On the other hand, when using the Graph SDK, the data comes back nicely wrapped in models that are easier to work with.

// Create Confidential Client
var clientApp = ConfidentialClientApplicationBuilder.Create(clientId)
    .WithClientSecret(clientSecret)
    .WithAuthority(new Uri($"https://login.microsoftonline.com/{tenantId}"))
    .Build();

// Get Token
var authResult = await clientApp.AcquireTokenForClient(scopes).ExecuteAsync();
string token = authResult.AccessToken;

// Call Graph API
var http = new HttpClient();
http.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", token);

var response = await http.GetAsync("https://graph.microsoft.com/v1.0/users");

var content = await response.Content.ReadAsStringAsync();

So, the question is: Where does the token handling happen in the ClientSecretCredential approach?

After digging deeper into the code, I found out that the ClientSecretCredential.GetTokenAsync() method is actually the one fetching the token for us.

public override async ValueTask<AccessToken> GetTokenAsync(TokenRequestContext requestContext, CancellationToken cancellationToken = default)
{
    using CredentialDiagnosticScope scope = _pipeline.StartGetTokenScope("ClientSecretCredential.GetToken", requestContext);

    try
    {
        var tenantId = TenantIdResolver.Resolve(TenantId, requestContext, AdditionallyAllowedTenantIds);

        // Here it fetches the token
        AuthenticationResult result = await Client.AcquireTokenForClientAsync(requestContext.Scopes, tenantId, requestContext.Claims, requestContext.IsCaeEnabled, true, cancellationToken).ConfigureAwait(false);

        return scope.Succeeded(result.ToAccessToken());
    }
    catch (Exception e)
    {
        throw scope.FailWrapAndThrow(e);
    }
}

Then, in the AzureIdentityAuthenticationProvider class, it adds the token to the request header in the AuthenticationRequestAsync() method.

public async Task AuthenticateRequestAsync(RequestInformation request, Dictionary<string, object>? additionalAuthenticationContext = default, CancellationToken cancellationToken = default)
{
    if(request == null) throw new ArgumentNullException(nameof(request));
    if(additionalAuthenticationContext != null &&
        additionalAuthenticationContext.ContainsKey(ClaimsKey) &&
        request.Headers.ContainsKey(AuthorizationHeaderKey))
        request.Headers.Remove(AuthorizationHeaderKey);

    if(!request.Headers.ContainsKey(AuthorizationHeaderKey))
    {
        var token = await AccessTokenProvider.GetAuthorizationTokenAsync(request.URI, additionalAuthenticationContext, cancellationToken);

        // Here, it adds the token to the header
        if(!string.IsNullOrEmpty(token))
            request.Headers.Add(AuthorizationHeaderKey, $"Bearer {token}");
    }
}

In the background, when you create a ClientSecretCredential(), it actually sets up an HttpClient for you. So when you call await graphClient.Users.GetAsync(), it triggers HttpClient.SendAsync(), and that's when the magic happens—AuthenticateRequestAsync() is called, the token is fetched, and then added to the request header.

Summary

When you call await graphClient.Users.GetAsync(), the GraphServiceClient triggers HttpClient.SendAsync()
Inside SendAsync(), AuthenticateRequestAsync() is called
In AuthenticateRequestAsync(), it fetched the token and adds it to the header
Then, the HTTP request is sent to the Graph API

Job done ☑️

Thanks for reading!

If you like this article, please don't hesitate to click the heart button ❤️
or follow my GitHub I'd appreciate it.

How to Join a PC to Active Directory—My Lazy Guide

FakeStandard — Fri, 12 Sep 2025 02:25:00 +0000

If you want to add a PC to Active Directory (AD), here are the prerequisites and steps to follow. This is a quick reference I wrote for myself in case I forget how to do it in the future.

🔥 Prerequisites

The PC must be running Windows Pro, Enterprise, or Education edition. (The Home edition can't join a domain)
You need to know the domain name, like domainname.com
Make sure your network is working properly. The PC must be able to resolve the domain via DNS, which usually means the DNS server should point to the DC.

📌 Steps

Open Control Panel > System > About
Click Rename this PC (Advanced)
In the Computer Name tab, click the Change button
Under Member of, select Domain and enter your domain name. (You can also rename your computer here, the new name will appear in AD.)
Restart your PC. On the login screen, check if you see the Other User option. If it appears, you can now sign in with a domain account.

📘 Notes

If your PC can't connect to the AD DC, check the network connection between the PC and the DC. Then, make sure the DNS settings are correct.

You can also refer to the previous article in this series—it might help you troubleshoot network-related issues.

Job done ☑️

Thanks for reading!

If you like this article, please don't hesitate to click the heart button ❤️
or follow my GitHub I'd appreciate it.

I Didn't Understand Program.cs in .NET, So I Wrote This

FakeStandard — Wed, 10 Sep 2025 06:05:00 +0000

When I created a new ASP.NET Core Web App (Model-View-Controller) project in .NET 8, I found there were some lines I didn't fully understand. So, I'm going to record what each line does and how it works.

Here's the full code in Program.cs

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddControllersWithViews();

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Home/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapControllerRoute(
    name: "default",
    pattern: "{controller=Home}/{action=Index}/{id?}");

app.Run();

The first and third lines are important in the project.

// Prepare the app's configuration and services.
var builder = WebApplication.CreateBuilder(args);

This is where the app starts. It creates a WebApplicationBuilder instance and loads configuration, sets up logging, dependency injection and environment settings.

// Build the app; it's ready to handle requests
var app = builder.Build();

This line builds the WebApplication instance based on everything set up in the builder.

// Enables MVC support for the app
builder.Services.AddControllersWithViews();

Registers services needed for MVC application into the DI container. It includes all the necessary services and configuration for MVC. So your application can use the MVC mode.

// In production, make the app more secure and don't expose detailed errors
if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Home/Error");
    app.UseHsts();
}

If the application is running in development mode, the developer exception page will be shown. Otherwise in a non-development environment, it shows a custom error page at /Home/Error.

Then app.UseHsts() enables HSTS, which enforces HTTPS.

Next, methods starting with the word Use configure the middleware. Each middleware is configured separately, such as HTTPS redirection, statice files, routing, and authorization, etc.

// Enforce users to connect via HTTPS
app.UseHttpsRedirection();

This line redirects all HTTP requests to HTTPS automatically.

// Clients can load static files
app.UseStaticFiles();

This line allows serving static files from the wwwroot folder only, such as CSS, JS, images, etc.

// The app can match URLs to the correct controller and action
app.UseRouting();

This line enables the routing system so the app can match incoming URLs to the correct controller and action.

// Check if the user has access rights
app.UseAuthorization();

It checks whether a user is allowed to access a route or resource.

app.MapControllerRoute(
    name: "default",
    pattern: "{controller=Home}/{action=Index}/{id?}");

This line defines the default route pattern.

app.Run();

Finally, this starts the application and begins listening for incoming HTTP requests.

Easy, right? Job done ☑️

Thanks for reading!

If you like this article, please don't hesitate to click the heart button ❤️
or follow my GitHub I'd appreciate it.

How to Quickly Test SQL Server Connection from a Client

FakeStandard — Tue, 09 Sep 2025 07:02:16 +0000

If you have a SQL Server environment and want to confirm if your client machines can connect to the database, how do you actually verify the connection is working?

Here's a quick rundown of the common ways I use every time I check a connection.

1️⃣ Use `sqlcmd` CLI Tool to Test Connection

This is probably the fastest way to test a SQL Server connection using the sqlcmd command line tool.

sqlcmd -S YourServerIP,1433 -U UserName -P Password

If the connection fails, it will show you the error details.

2️⃣ Test TCP/IP Connectivity with PowerShell

Sometimes the problem might be network-related, like firewall or port blocking. To verify if your client can reach the SQL Server's TCP port, use the following command in PowerShell.

Test-NetConnection -ComputerName yourserverip -Port 1433

If TcpTestSucceeded returns True, it means your client can communicate through port 1433 to the SQL Server.

3️⃣ Create a Console App to Test Connection

When you want to verify the connection from code, here's a minimal .NET 8 console app example using a connection string.

try
{
    using SqlConnection conn = new(connectionString);
    conn.Open();

    Console.WriteLine("Connection successful");
}
catch (Exception ex)
{
    Console.WriteLine(ex.Message);
}

Easy test. Job done ☑️

Thanks for reading!

If you like this article, please don't hesitate to click the heart button ❤️
or follow my GitHub I'd appreciate it.

Can't Connect to SQL Server? Check If TCP/IP and Firewall Are Enabled

FakeStandard — Mon, 08 Sep 2025 10:17:24 +0000

I tried to log in to SQL Server but got a following error

A connection was successfully established with the server, but then an error occurred during the login process (Error 233)

What causes this?

1️⃣ Review the Error Details

First, I checked the technical details of the error

Server Name: .
Error Number: 233
Severity: 20
State: 0

Error number 233 usually occurs the connection is successful, but rejects the login. So, we need to check if TCP/IP is enabled.

2️⃣ Enforce to Connect the TCP/IP

Change the serve name to tcp:127.0.0.1 without . or localhost.

If you still fail to log in and got the following error, proceed to enabled TCP/IP

Error Number: 1225
Severity: 20
State: 0

3️⃣ Check if TCP/IP is Enabled

Open SQL Server Configuration Manager
Expand SQL Server Network Configuration, then select Protocols for MSSQLSERVER or SQLEXPRESS
Enabled TCP/IP and Named Pipes
Restart SQL Server and try logging in again

4️⃣ Enable Firewall Rule for Port 1433

Your firewall might be blocking SQL Server's default port 1433. To fix this, enable the firewall rule using the command line.

netsh advfirewall firewall add rule name="SQL Server 1433" dir=in action=allow protocol=TCP localport=1433

Easy fix. Job done ☑️

Thanks for reading!

If you like this article, please don't hesitate to click the heart button ❤️
or follow my GitHub I'd appreciate it.

DEV Community: FakeStandard

Fetch API — Understanding Request.cache

🔍 The Six Cache Modes

🧩 Choosing the Right Cache Mode (Examples)

🍺 Wrapping Up

Understanding HTTP Content-Type

🔅 The Structure of Content-Type

🔍 What’s a MIME Type?

🍵 Setting Headers with Fetch API

Using the Fetch API

🔍 Basic Fetch Request

🌰 Request Configuration

🧩 Example

🍺 Wrapping Up

A Practical Guide to .NET Automatic Memory Management

🔍 Automatic Memory Management

🔅 Allocating Memory

🔋 Releasing Memory

🌀 Generations and Performance

💡 Key Points

A Practical Guide to .NET CLR, Managed and Unmanaged Code, and Interop

🔥 Common Language Runtime (CLR)

📗 What Is Managed Code

📘 What Is Unmanaged Code

📚 Interoperability (Interop)

🍺 Wrapping Up

Exploring .NET Dependency Injection Lifetimes with Real Examples

📌 What is Service Lifetime

🍵 How to Test

💡 Key points

🔎 When to use each lifetime？

🍺 Wrapping Up

Create a Custom Middleware in .NET

Simplifying Graph API Authentication with C#

How to Join a PC to Active Directory—My Lazy Guide

🔥 ​Prerequisites

📌 ​Steps

📘 ​Notes

I Didn't Understand Program.cs in .NET, So I Wrote This

How to Quickly Test SQL Server Connection from a Client

1️⃣ Use sqlcmd CLI Tool to Test Connection

2️⃣ Test TCP/IP Connectivity with PowerShell

3️⃣ Create a Console App to Test Connection

Can't Connect to SQL Server? Check If TCP/IP and Firewall Are Enabled

1️⃣ Review the Error Details

2️⃣ Enforce to Connect the TCP/IP

3️⃣ Check if TCP/IP is Enabled

4️⃣ Enable Firewall Rule for Port 1433

🔥 Prerequisites

📌 Steps

📘 Notes

1️⃣ Use `sqlcmd` CLI Tool to Test Connection