In ASP.NET Core development, configuration plays a very important role. Instead of hardcoding values in code, developers use a configuration system to manage settings like database connections, logging levels, API keys, and environment-specific values. The most commonly used configuration file is appsettings.json, and the main way to read these settings in your application is through IConfiguration. In this article, we will explain in simple terms how to use appsettings.json and IConfiguration with examples. All content is written to be SEO and GEO-friendly, so developers worldwide can easily understand.

What is appsettings.json?
The appsettings.json file is a JSON (JavaScript Object Notation) file used in ASP.NET Core applications to store configuration data. It acts like a central place where you keep application settings that may change depending on the environment.

Key Features

• Human-readable JSON format.
• Hierarchical structure (supports nested sections).
• Supports multiple environment files (e.g., appsettings.Development.json, appsettings.Production.json).
• Automatically loaded by ASP.NET Core at startup.

Example of appsettings.json
{
  "ConnectionStrings": {
    "DefaultConnection": "Server=localhost;Database=mydb;User Id=sa;Password=YourPassword;"
  },
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Warning"
    }
  },
  "AppSettings": {
    "ApplicationName": "My ASP.NET Core App",
    "Version": "1.0"
  }
}

What is IConfiguration?
The IConfiguration interface in ASP.NET Core is used to read values from appsettings.json (and other sources like environment variables, command-line arguments, or secrets). It provides a simple way to access settings by key.

Example of using IConfiguration
public class HomeController : Controller
{
    private readonly IConfiguration _configuration;

    public HomeController(IConfiguration configuration)
    {
        _configuration = configuration;
    }

    public IActionResult Index()
    {
        var appName = _configuration["AppSettings:ApplicationName"];
        var version = _configuration["AppSettings:Version"];
        ViewData["Message"] = $"{appName} - Version {version}";
        return View();
    }
}

Here, we are reading ApplicationName and Version from appsettings.json using IConfiguration.

Using Strongly Typed Classes for Configuration
Instead of accessing settings by string keys, ASP.NET Core allows binding configuration to classes. This makes the code cleaner, type-safe, and easier to maintain.

Example
public class AppSettings
{
    public string ApplicationName { get; set; }
    public string Version { get; set; }
}

In Program.cs:
builder.Services.Configure<AppSettings>(builder.Configuration.GetSection("AppSettings"));

In a Controller or Service:
public class HomeController : Controller
{
    private readonly AppSettings _appSettings;

    public HomeController(IOptions<AppSettings> appSettings)
    {
        _appSettings = appSettings.Value;
    }

    public IActionResult Index()
    {
        return Content($"App Name: {_appSettings.ApplicationName}, Version: {_appSettings.Version}");
    }
}

This approach is recommended for large applications because it makes managing configuration much easier.

Environment-Specific Configurations
ASP.NET Core supports different appsettings.json files for different environments such as Development, Staging, and Production.

    appsettings.Development.json

    appsettings.Staging.json

    appsettings.Production.json

Example of appsettings.Development.json

{
  "AppSettings": {
    "ApplicationName": "My Dev App",
    "Version": "1.0-DEV"
  }
}

When the application runs in Development mode, it will override values from appsettings.json with values from appsettings.Development.json. This makes it easy to have different settings for local testing, staging servers, and live production environments.

Security Best Practices
When using appsettings.json, it is important to handle sensitive information carefully.

• Do not store passwords or API keys directly in appsettings.json for production.
• Use User Secrets in development.
• Use Azure Key Vault, AWS Secrets Manager, or environment variables for production.

Example: Instead of keeping your database password in plain text, store it in an environment variable and let ASP.NET Core automatically load it into IConfiguration.

Summary
appsettings.json is the main file for configuration in ASP.NET Core, and IConfiguration is the service that reads these values. Developers can store important settings like connection strings, API keys, logging levels, and app information in appsettings.json. With the help of IConfiguration and strongly typed classes, these values can be accessed easily inside the application. By using environment-specific files and following security best practices, developers can build applications that are secure, flexible, and ready for global deployment. This approach makes ASP.NET Core applications scalable, maintainable, and cloud-ready.

What is mass assignment/overposting?

• Mass assignment happens when an API blindly binds all incoming JSON fields to your entity model, allowing attackers to set properties they shouldn’t.
• Example
• Suppose your User entity has a IsAdmin flag.

public class User
{
    public int Id { get; set; }
    public string Username { get; set; }
    public string Email { get; set; }
    public bool IsAdmin { get; set; }  //  Should never be set by the client
}

If your Web API controller does this:
[HttpPost]
public async Task<IActionResult> Register(User user)
{
    _context.Users.Add(user);
    await _context.SaveChangesAsync();
    return Ok(user);
}

An attacker can send:
{
  "username": "hacker",
  "email": "[email protected]",
  "isAdmin": true
}

Now the attacker registers themselves as Admin.
This is overposting (exposing unintended properties to clients).

How to Prevent Overposting in ASP.NET Core
1. Use DTOs (Data Transfer Objects)
Never expose your Entity models directly to the API.

Instead, use DTOs that only contain the fields you want the client to update.
public class RegisterDto
{
    [Required, StringLength(50)]
    public string Username { get; set; }

    [Required, EmailAddress]
    public string Email { get; set; }

    [Required, StringLength(100)]
    public string Password { get; set; }
}

Controller
[HttpPost("register")]
public async Task<IActionResult> Register(RegisterDto dto)
{
    var user = new User
    {
        Username = dto.Username,
        Email = dto.Email,
        IsAdmin = false //  Explicitly controlled
    };

    _context.Users.Add(user);
    await _context.SaveChangesAsync();

    return Ok("User registered successfully");
}

Only safe fields are accepted.

Sensitive properties ( IsAdmin ) are not exposed to binding.

2. Use Bind Attribute (MVC only, not Web API best practice)
You can restrict bound properties in MVC controllers with [Bind] .
public IActionResult Create([Bind("Username,Email,Password")] User user)
{ ... }

Not recommended for Web APIs—use DTOs instead.

3. Explicit Model Updates
When updating existing entities, don’t call Update() with the whole model.

Instead, the map only allowed properties.

Vulnerable
[HttpPut("{id}")]
public async Task<IActionResult> Update(int id, User user)
{
    _context.Update(user);  //  Overwrites everything, including IsAdmin
    await _context.SaveChangesAsync();
    return Ok(user);
}

Safe
[HttpPut("{id}")]
public async Task<IActionResult> Update(int id, UpdateUserDto dto)
{
    var user = await _context.Users.FindAsync(id);
    if (user == null) return NotFound();

    // Only update safe fields
    user.Username = dto.Username;
    user.Email = dto.Email;

    await _context.SaveChangesAsync();
    return Ok(user);
}

4. Automapper with Explicit Mapping
If using AutoMapper, configure mappings carefully:
CreateMap<RegisterDto, User>()
.ForMember(dest => dest.IsAdmin, opt => opt.Ignore()); // Prevent assignment

5. Use TryUpdateModelAsync with Property Whitelisting
If you want to bind selectively:
await TryUpdateModelAsync(user, "",
u => u.Username, u => u.Email);

6. Audit Sensitive Fields
Even with DTOs, add server-side checks to ensure properties like IsAdmin , Balance , Role , etc. are only modified by authorized users.

Example
if (dto.Role != null && !User.IsInRole("Admin"))
{
    return Forbid();
}

Best Practices Checklist

• Always use DTOs instead of binding entities directly.
• Whitelist properties explicitly (DTOs, TryUpdateModelAsync , AutoMapper configs).
• Do not expose sensitive properties (e.g., IsAdmin , Balance , CreatedDate ).
• Never call _context.Update(entity) blindly —update only safe fields.
• Audit sensitive updates with role-based authorization.

Conclusion
Mass assignment/overposting is a silent but dangerous vulnerability in ASP.NET Core Web APIs. By using DTOs, explicit property mapping, and whitelisting techniques, you ensure that attackers cannot overwrite sensitive fields.

Always remember:
Bind only what you trust; never trust what you bind.

When you click on a link on a typical website, the browser loads a brand-new page from the server. This could be sluggish and result in a visible lag, which would force a page refresh. Single-Page Applications (SPAs) were developed to increase performance and user experience. They give online apps the same speed and fluidity as mobile apps.

What is a Single-Page Application?
A Single-Page Application (SPA) is a type of web application that loads a single HTML page and dynamically updates the content as the user interacts with it. Instead of reloading the whole page, only the necessary data is fetched and shown.

Key Features

• Loads Once: The main page loads only once, and further content loads dynamically.
• No Full Page Reloads: Content changes without refreshing the entire page.
• Fast Navigation: Feels smooth and similar to using a native mobile app.
• Heavy Use of JavaScript: SPAs rely on JavaScript frameworks and APIs.

How do SPAs Work?

• SPAs work by using JavaScript to handle routing and update the page's content.
• Initial Load: The browser loads one main HTML, CSS, and JavaScript file.
• User Interaction: When the user clicks a button or link, JavaScript intercepts it.
• Data Fetching: The application requests only the necessary data from the server using APIs (such as AJAX or Fetch).
• Dynamic Update: JavaScript updates only part of the page without a full reload.

Example

• If you use Gmail in your browser.
• When you click on an email, only the email content loads while the sidebar and top menu stay the same.
• This is a perfect example of an SPA. (Language: JavaScript with frameworks like React or Angular)

Technologies Used in SPAs
SPAs depend heavily on JavaScript and frontend frameworks.
Common Frameworks and Libraries:

• React.js: Widely used for building SPAs.
• Angular: A complete framework for large SPAs.
• Vue.js: A simple and flexible option for SPAs.
• Svelte: A newer framework for building SPAs efficiently.

Supporting Tools:

• AJAX / Fetch API: To request data without reloading the page.
• REST APIs / GraphQL: To fetch and send data between frontend and backend.

Advantages of SPAs

• Fast Performance: After the first load, navigation is speedy.
• Better User Experience: Smooth transitions without page reloads.
• Reusable Components: Developers can reuse UI components.
• Mobile App Feel: Feels more interactive, like a mobile application.
• Reduced Server Load: Only the required data is requested.

Disadvantages of SPAs

• Initial Load Time: The first page may take longer to load because JavaScript files are heavy.
• SEO Challenges: Search engines may struggle to index SPAs properly.
• Browser Compatibility: Requires JavaScript; may not work well if disabled.
• Security Risks: Exposed APIs can be targeted if not adequately secured.

Real-World Examples of SPAs

• Gmail: Only updates email content without reloading the entire page.
• Google Maps: Loads the map once and dynamically updates locations.
• Facebook: Clicking posts and comments updates the page instantly.
• Twitter: New tweets load dynamically without a full refresh.

Summary
Single-Page Applications (SPAs) are modern web applications that load a single main HTML page and dynamically update its content as users interact. They provide faster navigation, smoother experiences, and a mobile app-like feel. SPAs are built using JavaScript frameworks like React, Angular, and Vue. While they improve performance and user experience, they also face challenges like SEO issues and heavy initial load times. In short, SPAs are a powerful choice for building interactive and modern web applications.

Understanding CommandResponse<T> in C#
When building applications, it’s common to write methods that need to return data along with the status of execution (success or failure). Instead of just returning raw data or a boolean, a better approach is to use a wrapper response object.
What is CommandResponse<T>?

CommandResponse<T> is a generic wrapper class that can hold:

• Data: the actual result of the operation.
• Errors: a list of errors if something went wrong.
• Success: a quick way to check if the operation succeeded.

It can be challenging to manage packages in a.NET solution with numerous projects.  You've probably seen issues like this if you've worked on big apps with dozens or even hundreds of projects.

• Projects utilizing various iterations of the same NuGet package are known as version mismatches.
• Manual labor: Each must be updated. csproj files one after the other.
• Build failures: CI/CD pipelines malfunctioning due to mismatched package versions.

To make this easier, Microsoft introduced Central Package Management (CPM) in .NET, starting with NuGet 6.0 and SDK-style projects.

What is Central Package Management?
Central Package Management lets you keep all NuGet package versions in one central file for your solution. Instead of writing the version number in every project file, you set it once in a file called Directory.Packages.props, and all projects use that version.

This makes upgrades easier, keeps versions consistent, and reduces maintenance work.

How It Works
Create a central file:
At the solution’s root, add a file named Directory.Packages.props.
<Project>
  <PropertyGroup>
    <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
  </PropertyGroup>
  <ItemGroup>
    <PackageVersion Include="Newtonsoft.Json" Version="13.0.3" />
    <PackageVersion Include="RabbitMQ.Client" Version="7.1.2" />
    <PackageVersion Include="Swashbuckle.AspNetCore" Version="9.0.3" />
  </ItemGroup>
</Project>

Central Package Management
2. Reference packages in projects (without specifying versions):
<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Newtonsoft.Json" />
    <PackageReference Include="RabbitMQ.Client" />
  </ItemGroup>

</Project>

Central Package Management
Note: The project file doesn’t include a version number. Instead, the version is defined in Directory.Packages.props.

3. Automatic adoption:
The .NET SDK automatically finds the Directory.Packages.props file in your solution folder and applies it to all projects.

Benefits of Central Package Management

• Consistency – Every project uses the same package version, avoiding conflicts.
• One place to update – Change the version in a single file instead of many.
• Fewer code conflicts – No version mismatches in .csproj files.
• Reliable builds – CI/CD pipelines run more smoothly.
• Simpler project files – .csproj files stay clean and easy to read.

Here’s a simpler example with different packages:
Suppose you have a solution with 15 projects, all using Newtonsoft.Json. Without CPM, updating it means changing 15 .csproj files.

With CPM, you just add this to Directory.Packages.props:
<PackageVersion Include="Newtonsoft.Json" Version="13.0.3" />

Now all projects use the new version automatically.

Conclusion
Central Package Management (CPM) in .NET makes life easier for teams working on solutions with many projects. It keeps package versions consistent, simplifies updates, and saves time. If you haven’t tried it yet, create a Directory.Packages.props file in your solution. You’ll quickly see the advantages. Happy Coding!

When you first encounter the Readonly keyword in C#, it seems straightforward, prevent fields from being reassigned after construction. But once you start applying it to reference types, things get more nuanced. We’ll break down what Readonly really means, especially when dealing with objects, how it behaves differently with value vs. reference types, and what developers should keep in mind to write safer, cleaner code.

What Does Readonly Actually Do?
In C#, the Readonly keyword:

• Can be applied to fields.
• Ensures the field can only be assigned during declaration or inside the constructor of the class/struct.
• Once assigned, the field can’t point to a different object.

public class User
{
    public string Name { get; set; }
}

public class Account
{
    private readonly User _user = new User();
    public void ChangeUser()
    {
        // This is possible
        _user.Name = "New Name";
        // But this will result in compile-time error
        _user = new User();
    }
}

Misunderstanding:
A Readonly field of a reference type doesn’t make the object itself immutable, it only means the reference can’t be reassigned. You can still modify the object’s internal state.
Reference Types vs. Value Types with Readonly

Value Types:
readonly int number = 5;
// Compile-time error
number = 10;

With value types (like int, bool, struct), Readonly means you cannot change the value.
Reference Types:
readonly List<string> items = new List<string>();
// Possible
items.Add("Test");
// Compile-time error
items = new List<string>();

So, the object can still mutate , it’s the reference that’s locked.

Then, How to Make Reference Types Truly Immutable?
To make an object’s state immutable, you must:

• Avoid set accessors in properties.
• Make all fields Readonly.
• Use init accessors for initialization only.
• Don’t expose collection fields directly.

Example
public class User
{
    public string Name { get; init; }
}

Readonly with Properties
While Readonly can be used on fields, it cannot be directly used on properties. But you can mimic the behavior using init accessor:
public string Role { get; init; } = "admin";

These make the property immutable after initialization.

This article guides you through creating a simple Employee Management System with CRUD functionality using.

• Backend: ASP.NET Core Web API
• Frontend: React.js
• Database: SQL Server (via Entity Framework Core)

Step 1. Backend Setup - ASP.NET Core Web API
1.1. Create Project
Run this command on bash.
dotnet new webapi -n EmployeeAPI
cd EmployeeAPI

1.2. Add EF Core Packages
dotnet add package Microsoft.EntityFrameworkCore.SqlServer
dotnet add package Microsoft.EntityFrameworkCore.Tools

1.3. Create Employee Model
// Models/Employee.cs
namespace EmployeeAPI.Models
{
    public class Employee
    {
        public int Id { get; set; }
        public string Name { get; set; }
        public string Department { get; set; }
        public decimal Salary { get; set; }
    }
}

1.4. Create DbContext
// Data/EmployeeContext.cs
using Microsoft.EntityFrameworkCore;
using EmployeeAPI.Models;

namespace EmployeeAPI.Data
{
    public class EmployeeContext : DbContext
    {
        public EmployeeContext(DbContextOptions<EmployeeContext> options)
            : base(options)
        {
        }
        public DbSet<Employee> Employees { get; set; }
    }
}

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

1.6. Add Connection String to appsettings.json
"ConnectionStrings": {
  "DefaultConnection": "Server=YOUR_SERVER;Database=EmployeeDb;Trusted_Connection=True;"
}

using Microsoft.AspNetCore.Mvc;
using EmployeeAPI.Data;
using EmployeeAPI.Models;
using Microsoft.EntityFrameworkCore;

[ApiController]
[Route("api/[controller]")]
public class EmployeesController : ControllerBase
{
    private readonly EmployeeContext _context;

    public EmployeesController(EmployeeContext context) => _context = context;

    [HttpGet]
    public async Task<ActionResult<IEnumerable<Employee>>> GetEmployees() =>
        await _context.Employees.ToListAsync();

    [HttpGet("{id}")]
    public async Task<ActionResult<Employee>> GetEmployee(int id)
    {
        var emp = await _context.Employees.FindAsync(id);
        return emp == null ? NotFound() : emp;
    }

    [HttpPost]
    public async Task<ActionResult<Employee>> CreateEmployee(Employee emp)
    {
        _context.Employees.Add(emp);
        await _context.SaveChangesAsync();
        return CreatedAtAction(nameof(GetEmployee), new { id = emp.Id }, emp);
    }

    [HttpPut("{id}")]
    public async Task<IActionResult> UpdateEmployee(int id, Employee emp)
    {
        if (id != emp.Id)
            return BadRequest();

        _context.Entry(emp).State = EntityState.Modified;
        await _context.SaveChangesAsync();

        return NoContent();
    }

    [HttpDelete("{id}")]
    public async Task<IActionResult> DeleteEmployee(int id)
    {
        var emp = await _context.Employees.FindAsync(id);
        if (emp == null)
            return NotFound();

        _context.Employees.Remove(emp);
        await _context.SaveChangesAsync();

        return NoContent();
    }
}

1.7. Run Migrations
dotnet ef migrations add InitialCreate
dotnet ef database update

Step 2. Frontend Setup - React.js
2.1. Create React App
npx create-react-app employee-ui
cd employee-ui

2.2. Install Axios
npm install axios

2.3. Create API Service
// src/services/employeeService.js

import axios from 'axios';
const API_URL = 'https://localhost:5001/api/employees';
export const getEmployees = () => axios.get(API_URL);
export const getEmployee = (id) =>
  axios.get(`${API_URL}/${id}`);
export const addEmployee = (data) =>
  axios.post(API_URL, data);
export const updateEmployee = (id, data) =>
  axios.put(`${API_URL}/${id}`, data);
export const deleteEmployee = (id) =>
  axios.delete(`${API_URL}/${id}`);

JavaScript
2.4. Main Component Example

// src/App.js
import React, { useEffect, useState } from 'react';
import * as employeeService from './services/employeeService';

function App() {
  const [employees, setEmployees] = useState([]);
  const [form, setForm] = useState({ name: '', department: '', salary: '' });
  const [editId, setEditId] = useState(null);

  const fetchData = async () => {
    const res = await employeeService.getEmployees();
    setEmployees(res.data);
  };

  useEffect(() => {
    fetchData();
  }, []);

  const handleSubmit = async (e) => {
    e.preventDefault();
    if (editId) {
      await employeeService.updateEmployee(editId, form);
    } else {
      await employeeService.addEmployee(form);
    }
    setForm({ name: '', department: '', salary: '' });
    setEditId(null);
    fetchData();
  };

  const handleEdit = (emp) => {
    setForm(emp);
    setEditId(emp.id);
  };

  const handleDelete = async (id) => {
    await employeeService.deleteEmployee(id);
    fetchData();
  };

  return (
    <div>
      <h2>Employee Management</h2>
      <form onSubmit={handleSubmit}>
        <input
          value={form.name}
          onChange={(e) => setForm({ ...form, name: e.target.value })}
          placeholder="Name"
          required
        />
        <input
          value={form.department}
          onChange={(e) => setForm({ ...form, department: e.target.value })}
          placeholder="Department"
          required
        />
        <input
          value={form.salary}
          onChange={(e) => setForm({ ...form, salary: e.target.value })}
          placeholder="Salary"
          required
          type="number"
        />
        <button type="submit">{editId ? 'Update' : 'Add'}</button>
      </form>

      <ul>
        {employees.map((emp) => (
          <li key={emp.id}>
            {emp.name} ({emp.department}) - ${emp.salary}
            <button onClick={() => handleEdit(emp)}>Edit</button>
            <button onClick={() => handleDelete(emp.id)}>Delete</button>
          </li>
        ))}
      </ul>
    </div>
  );
}

export default App;

Step 3. Enable CORS in .NET Core
builder.Services.AddCors(options =>
{
    options.AddPolicy("AllowReactApp", policy =>
        policy.WithOrigins("http://localhost:3000")
              .AllowAnyMethod()
              .AllowAnyHeader());
});

app.UseCors("AllowReactApp");

Step 4. Run the Projects
Run backend
dotnet run

Run frontend
npm start

Output
A simple UI to.

• List employees
• Add a new employee
• Edit existing employee
• Delete employee

Summary
This full-stack CRUD project demonstrated how to.

• Create and expose RESTful APIs in ASP.NET Core
• Connect SQL Server using EF Core
• Consume those APIs in React
• Use Axios for API calls
• Enable CORS between frontend and backend

I discovered that Swagger can be used for much more than just simple API description, particularly in practical tasks. Advanced use cases like grouping endpoints, allowing versioning, using JWT to secure Swagger, and even hiding endpoints when necessary have improved the efficiency and professionalism of my development approach. In addition to code snippets, advice, and things to avoid, I'm revealing the Swagger features that I really use in.NET 6, 7, and 8 projects in this post.

1. Grouping Endpoints (Using Tags)
Sometimes your Swagger UI becomes overwhelming with too many endpoints. Grouping them into logical sections makes it easier to navigate.

Option 1. Group by controller name (default)
This happens automatically, but you can customize it further.

Option 2. Use [ApiExplorerSettings(GroupName = "v1")]
Or use SwaggerDoc and define multiple groups.
// Program.cs
builder.Services.AddSwaggerGen(c =>
{
    c.SwaggerDoc("v1", new OpenApiInfo { Title = "My API V1", Version = "v1" });
    c.SwaggerDoc("v2", new OpenApiInfo { Title = "My API V2", Version = "v2" });
});

// Controller
[ApiExplorerSettings(GroupName = "v2")]
[Route("api/v2/[controller]")]
public class OrdersController : ControllerBase
{
    //...
}

Now, Swagger UI will show v1 and v2 as tabs.

2. API Versioning in Swagger
If your app supports multiple API versions, Swagger should reflect that. Here’s how to set it up.

Step 1. Add required NuGet packages
dotnet add package Microsoft.AspNetCore.Mvc.Versioning
dotnet add package Microsoft.AspNetCore.Mvc.Versioning.ApiExplorer

Step 2. Configure versioning
builder.Services.AddApiVersioning(options =>
{
    options.ReportApiVersions = true;
    options.AssumeDefaultVersionWhenUnspecified = true;
    options.DefaultApiVersion = new ApiVersion(1, 0);
});

builder.Services.AddVersionedApiExplorer(options =>
{
    options.GroupNameFormat = "'v'VVV";
    options.SubstituteApiVersionInUrl = true;
});

Step 3. Update SwaggerGen
builder.Services.AddSwaggerGen();
builder.Services.ConfigureOptions<ConfigureSwaggerOptions>();

(You’ll need to create a ConfigureSwaggerOptions class — I can generate this for you if needed.)

3. Add JWT Authentication to Swagger UI
If you're using JWT Bearer tokens, you can allow Swagger to send them in request headers.

Configure Swagger with Security Definitions
builder.Services.AddSwaggerGen(c =>
{
    c.AddSecurityDefinition("Bearer", new OpenApiSecurityScheme
    {
        Description = "Enter 'Bearer' followed by your JWT token.",
        Name = "Authorization",
        In = ParameterLocation.Header,
        Type = SecuritySchemeType.ApiKey,
        Scheme = "Bearer"
    });

    c.AddSecurityRequirement(new OpenApiSecurityRequirement
    {
        {
            new OpenApiSecurityScheme
            {
                Reference = new OpenApiReference
                {
                    Type = ReferenceType.SecurityScheme,
                    Id = "Bearer"
                }
            },
            Array.Empty<string>()
        }
    });
});

Now Swagger UI will show an Authorize button at the top where you can paste your token.

4. Hiding Specific Endpoints from Swagger
Sometimes you don’t want every endpoint exposed in Swagger, especially internal or admin-only APIs.

Option. Use [ApiExplorerSettings(IgnoreApi = true)]
[ApiExplorerSettings(IgnoreApi = true)]
[HttpGet("internal-only")]
public IActionResult HiddenEndpoint()
{
    return Ok("This won't appear in Swagger");
}

Works at both the action and controller level.

5. Export Swagger JSON/YAML
You can share your API contract with clients or import it into tools like Postman or Azure API Management.
JSON endpoint:
https://localhost:5001/swagger/v1/swagger.json

YAML: You’ll need a separate generator, or use tools like Swagger Editor or SwaggerHub to convert JSON to YAML.

6. Improve Models with DataAnnotations
Swagger auto-generates schemas from your models. Enhance them with [Required], [StringLength], and summaries.
public class ProductDto
{
    [Required]
    [StringLength(50)]
    public string Name { get; set; }

    /// <summary>Product price in USD</summary>
    public decimal Price { get; set; }
}

Make sure XML comments are enabled to see them in the UI.

7. UI Customizations (Logo, Layout, etc.)
You can style Swagger UI by injecting CSS or JS.
app.UseSwaggerUI(c =>
{
    c.InjectStylesheet("/swagger-ui/custom.css");
    c.DocumentTitle = "My API Docs";
});

Use this to:

• Add your company logo
• Change the default collapsed/expanded state
• Customize font/colors

Best Practices I Follow

Conclusion
When you go beyond the basics, Swagger becomes a powerful tool, not just for docs, but for API governance and developer experience. These advanced use cases have helped me a lot when working with large APIs and teams. If you’re already using Swagger in your .NET app, I highly recommend trying out a few of these. They’re not hard to implement, and the payoff is worth it.

JavaScript is frequently used in contemporary web development to create interactive user interfaces. But now that Blazor has been released, Microsoft has given.NET developers the ability to create sophisticated, client-side web apps with C# rather than JavaScript. Blazor supports both client-side and server-side application models and is a component of the ASP.NET Core ecosystem.

What is Blazor?
Blazor is a web UI framework that allows developers to build interactive web UIs using C#. It runs in two main modes:

• Blazor Server: Runs the application on the server and uses SignalR to manage UI interactions.
• Blazor WebAssembly: Runs entirely on the browser using WebAssembly to execute C# code client-side.

Blazor combines the flexibility of modern web development with the productivity of .NET.

Key Features of Blazor

• Component-based architecture for building reusable UI blocks.
• Full .NET support — use C#, Razor, and existing .NET libraries.
• Two-way data binding for easy synchronization of data and UI.
• Dependency injection built-in.
• Routing, event handling, and JavaScript interop support.

Blazor Development Workflow

1. Prerequisites
.NET SDK (.NET 8 or later)
Visual Studio 2022+ or Visual Studio Code
Blazor WebAssembly or Server project template

2. Create a New Project
Using CLI
​dotnet new blazorserver -o BlazorApp

or for WebAssembly
dotnet new blazorwasm -o BlazorApp

3. Project Structure

• Pages/: Razor components (.razor files)
• Shared/: Reusable layout or menu components
• Program.cs: App startup and service configuration
• _Imports.razor: Global namespaces for all components

4. Build and Run
cd BlazorApp dotnet run
Then open http://localhost:5000 in your browser.

Simple Example: Counter Component
<h3>Counter</h3> <p>Current count: @count</p> <button class="btn btn-primary" @onclick="IncrementCount">Click me</button> @code { private int count = 0; private void IncrementCount() { count++; } }

This is a basic component showing a counter that increments when the button is clicked. It's fully written in Razor and C# — no JavaScript involved.

Use Cases for Blazor

• Enterprise internal tools and dashboards
• Form-driven business applications
• Interactive reporting interfaces
• Progressive Web Apps (PWAs)

Best Practices

• Break UIs into reusable components.
• Use state management properly for large apps.
• Secure APIs and validate user inputs.
• Use JavaScript interop only when necessary.
• Monitor performance in WebAssembly mode for large apps.

Conclusion
Blazor is revolutionizing web development by enabling full-stack C# development. With its flexible architecture, developer-friendly tooling, and integration with the .NET ecosystem, Blazor is an ideal choice for modern, scalable web applications. Whether you're building line-of-business apps or looking to transition from JavaScript frameworks, Blazor provides a productive and powerful alternative.

Applications commonly depend on external databases, services, and APIs to operate in today's distributed systems and microservices architecture. High traffic, network problems, or temporary difficulties can cause certain dependencies to fail. It is our responsibility as developers to build apps that can gracefully handle such failures. Resilience patterns can help with that. We will use the most recent Polly v8 coupled with Microsoft to construct middleware for Retry and Circuit Breaker in this blog. extensions. tenacity.

When should I use a circuit breaker? What is its pattern?
Modern applications employ the Circuit Breaker design pattern to avoid invoking a service or function that is prone to malfunction. Consider it analogous to your home's electric circuit breaker, which trips and cuts off the electrical supply in the event of an overload to guard against harm. In software, a circuit breaker momentarily halts calls to a malfunctioning service in order to prevent further overloading it.

When Should You Use It?

• When an external service is known to fail frequently.
• When you want to fail fast instead of waiting for timeouts.
• To prevent cascading failures in microservices.
• To improve overall system responsiveness and stability.

Circuit Breaker Flow

What is Polly?
Polly is a .NET resilience and transient-fault-handling library that allows developers to express policies such as Retry, Circuit Breaker, Timeout, Bulkhead Isolation, and Fallback. Polly has been widely adopted in the .NET community, and with Polly v8, Microsoft has introduced deep integration into the Microsoft.Extensions ecosystem through the new Microsoft.Extensions.Resilience package.

Polly with Microsoft.Extensions.Resilience
In Polly v8, resilience is more declarative and integrated into .NET’s dependency injection and configuration model. This makes it easier to build policies that are environment-aware and configurable. Let’s start building our retry and circuit breaker middleware using the latest packages.

Step 1. Set Up Your Project
Create a new web API project in Visual Studio, or if you are using Visual Studio Code, you can execute the following commands.
mkdir PollyResilienceApp
cd PollyResilienceApp
dotnet new PollyV8RetryDemo

Post that adds below the NuGet package
# In case of Visual Studio Code
dotnet add package Microsoft.Extensions.Resilience

# In case of Visual Studio Package Manager Console
NuGet\Install-Package Microsoft.Extensions.Resilience

Step 2. Configure Resilience Policies in the Program.cs
Open the Program.cs file and add the required namespace and Poly service to place it in the middleware. Below is the snippet of Program.cs file with service.
// namespaces
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Resilience;

var builder = WebApplication.CreateBuilder(args);

// add service
builder.Services.AddResiliencePipeline("standard-pipeline", pipelineBuilder =>
{
    // add retry configurations
    pipelineBuilder.AddRetry(new RetryStrategyOptions
    {
        MaxRetryAttempts = 3,  // -> this should be from appSettings.json
        Delay = TimeSpan.FromMilliseconds(500), // -> this should be from appSettings.json
        BackoffType = DelayBackoffType.Exponential
    });

    // set the circuit breaker pattern
    // configuration numbers should be driven from appSettings.json
    pipelineBuilder.AddCircuitBreaker(new CircuitBreakerStrategyOptions
    {
        FailureRatio = 0.5,  // -> this should be from appSettings.json
        SamplingDuration = TimeSpan.FromSeconds(30),
        MinimumThroughput = 10,
        BreakDuration = TimeSpan.FromSeconds(15)
    });
});

var app = builder.Build();

app.MapControllers();

app.Run();

Step 3. Inject and Use the Policy in a Controller
Once you set the service in the program.cs, it is time to inject the same in the Controllers. Below is an example of a sample controller where ResiliencePipelineProvider has been injected to execute
using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Resilience;

[ApiController]
[Route("api/[controller]")]
public class MyAPIController : ControllerBase
{
    private readonly ResiliencePipelineProvider<string> _pipelineProvider;

    public MyAPIController(ResiliencePipelineProvider<string> pipelineProvider)
    {
        _pipelineProvider = pipelineProvider;
    }

    [HttpGet("execute")]
    public async Task<IActionResult> Execute_v1()
    {
        var pipeline = _pipelineProvider.GetPipeline("standard-pipeline");

        try
        {
            var result = await pipeline.ExecuteAsync(async token =>
            {
                // Actual operations goes here
                // For test, can place an sleep command
                // await Task.Delay(100);
                throw new HttpRequestException("Failure");
            });

            return Ok(result);
        }
        catch (Exception ex)
        {
            return StatusCode(500, $"Operation failed: {ex.Message}");
        }
    }
}

How Polly Helps Achieve the Circuit Breaker Pattern?
Polly allows you to plug in the circuit breaker logic without cluttering your business code. The resilience pipeline acts as a middleware that surrounds your code, monitoring failures, retries, and triggering breaks when needed.

With Polly, you get:

• Observability: You can plug in logging and metrics easily.
• Composability: You can combine Retry + Circuit Breaker + Timeout.
• Declarative configuration: Adjust thresholds without touching the logic.

The diagram below explains how the request is flowing.

While all the retry actions are executing by Polly, logs can be done through the Logging Service. To enable the same, add the following code snippet in Program.cs. Appenders can be used based on the project needs.
builder.Services.AddLogging();

Conclusion
By integrating Polly v8 with Microsoft.Extensions.Resilience, you can build reliable, maintainable, and production-ready applications in .NET. Using the Retry and Circuit Breaker patterns, you shield your applications from transient errors and cascading failures.

If you’re building services at scale or working in a microservices environment, implementing these patterns is not just a good-to-have but a necessity.