DEV Community: Rupinder Kaur

How to Use Code Metrics in .NET to Refactor Complex API Controllers

Rupinder Kaur — Thu, 05 Feb 2026 03:37:38 +0000

Have you ever opened an API controller and thought, “Whoa, this looks like spaghetti”? 😵‍💫 If you’re working with legacy .NET projects or scaling up a growing codebase, complexity can creep in quickly. That’s where Visual Studio’s Code Metrics come to the rescue.

In this post, I’ll walk you through:

What each code metric means
How to use them to identify messy code
A real-life example of refactoring a bloated API controller
A checklist to guide your review process

Let’s dive in! 🧩

🔍 What Are Code Metrics?

Code metrics help quantify how maintainable, complex, and testable your code is. Visual Studio provides these metrics via:

Analyze → Analyze Code Metrics

🖼️ Image: Visual Studio Code Metrics Panel

A screenshot of Visual Studio’s Code Metrics results showing Maintainability Index, Cyclomatic Complexity, etc.

📊 Code Metrics Explained

Here’s what each metric means and why it matters:

1. Maintainability Index (MI)

Definition: A numeric score (0–100) indicating how easy it is to maintain a code element.
✅ 80–100: Easy to maintain
⚠️ 50–79: Moderate
❌ 0–49: Hard to maintain

2. Cyclomatic Complexity (CC)

Definition: The number of independent paths through the code. Increases with if, switch, for, etc.
✅ <10: Simple
⚠️ 10–20: Moderate
❌ >20: Complex

3. Depth of Inheritance

Definition: The number of class levels above the current class in the hierarchy.
✅ 0–3: Ideal
❌ >4: May be problematic

4. Class Coupling

Definition: Number of external classes/types referenced.
✅ <10: Low coupling (preferred)
❌ >20: High coupling (bad for maintainability)

5. Lines of Executable Code

Definition: Number of actual executable lines of code (ignores comments/braces).
✅ <200 per class, <50 per method
❌ >500: Too complex, consider breaking apart

🖼️ Image: Metric Definitions Heatmap Table

A visual summary showing good, warning, and bad ranges for each metric (green-yellow-red).

✅ Code Metrics Review Checklist

Here’s a handy checklist to evaluate your API controllers or classes:

[ ] MI < 50? Refactor needed!
[ ] CC > 10? Simplify or extract methods.
[ ] Inheritance depth > 3? Consider flattening it.
[ ] Class coupling > 10? Break dependencies, inject interfaces.
[ ] Too many LOC? Break into smaller classes/services.

🧪 Real-Life Example: Refactoring a Bloated API Controller

Let’s say you have this OrdersController. Everything works, but the code smells.

public class OrdersController : ControllerBase
{
    [HttpPost]
    public async Task<IActionResult> CreateOrder(OrderDto dto)
    {
        if (dto == null || dto.Items.Count == 0)
            return BadRequest("Invalid order");

        var customer = await _context.Customers.FindAsync(dto.CustomerId);
        if (customer == null)
            return NotFound("Customer not found");

        var order = new Order
        {
            CustomerId = dto.CustomerId,
            CreatedAt = DateTime.UtcNow,
            Items = dto.Items.Select(x => new OrderItem
            {
                ProductId = x.ProductId,
                Quantity = x.Quantity,
                Price = x.Price
            }).ToList()
        };

        _context.Orders.Add(order);
        await _context.SaveChangesAsync();

        _logger.LogInformation($"Order {order.Id} created");

        return Ok(order.Id);
    }
}

🖼️ Image: OrdersController Before Refactor

Highlight that business logic, DB operations, and validation are all mixed in the controller.

⚠️ Code Metrics Report

Metric	Value	Issue
Maintainability Index	47 ❌	Too low
Cyclomatic Complexity	15 ⚠️	Too many branches
Class Coupling	12 ⚠️	High dependencies
Executable LOC	80 ⚠️	Too much logic in one method

🔧 Refactoring Plan

We move logic to a new OrderService.

public class OrderService : IOrderService
{
    public async Task<int> CreateOrderAsync(OrderDto dto)
    {
        var customer = await _context.Customers.FindAsync(dto.CustomerId)
                      ?? throw new Exception("Customer not found");

        var order = new Order
        {
            CustomerId = dto.CustomerId,
            CreatedAt = DateTime.UtcNow,
            Items = dto.Items.Select(x => new OrderItem
            {
                ProductId = x.ProductId,
                Quantity = x.Quantity,
                Price = x.Price
            }).ToList()
        };

        _context.Orders.Add(order);
        await _context.SaveChangesAsync();
        _logger.LogInformation($"Order {order.Id} created");

        return order.Id;
    }
}

Updated controller:

[HttpPost]
public async Task<IActionResult> CreateOrder(OrderDto dto)
{
    try
    {
        var orderId = await _orderService.CreateOrderAsync(dto);
        return Ok(orderId);
    }
    catch (Exception ex)
    {
        _logger.LogError(ex, "Error creating order");
        return BadRequest(ex.Message);
    }
}

🖼️ Image: Refactored Architecture Diagram

Show controller → service → dbContext pattern (clean layering).

🎯 After Refactoring Metrics

Metric	Value	Improvement
Maintainability Index	90 ✅	Big boost
Cyclomatic Complexity	3 ✅	Clean logic
Class Coupling	4 ✅	Reduced
Executable LOC	20 ✅	Much leaner

🖼️ Image: Before vs After Metrics Bar Chart

Visual comparison of metric values before and after refactoring.

🧠 Lessons Learned

Metrics are not just numbers—they’re clues to identify code smells.
Refactoring based on metrics leads to better testability, scalability, and developer happiness.
Good architecture grows from clean, measurable decisions.

🛠 Bonus: Automate It in CI/CD

You can integrate metrics analysis into your DevOps pipeline using:

🔍 Roslyn Analyzers
🧠 NDepend
🌊 SonarQube
🛠️ dotnet code-quality tools

🖼️ Image: CI/CD Quality Gate Flowchart

Show code → build → analyze → quality gate → deploy.

🧾 Final Thoughts

Taking time to analyze and improve code complexity today will save you countless hours of debugging and scaling pain tomorrow. Start small—run metrics on one class per sprint.

🔁 Refactor. 🔬 Measure. ✅ Repeat.

💬 How do you manage complexity in your .NET projects? Share your tips below!

✍️ Written by Rupinder Kaur, a Senior .NET Developer passionate about clean architecture, refactoring, and continuous improvement.

Code Smells in .NET? Use These Visual Studio Metrics to Refactor Smartly

Rupinder Kaur — Thu, 05 Feb 2026 03:36:26 +0000

Have you ever opened an API controller and thought, “Whoa, this looks like spaghetti”? If you’re working with legacy .NET projects or scaling up a growing codebase, complexity can creep in quickly. That’s where Visual Studio’s Code Metrics come to the rescue.

In this post, I’ll walk you through:

What each code metric means
How to use them to identify messy code
A real-life example of refactoring a bloated API controller
A checklist to guide your review process

Let’s dive in!

What Are Code Metrics?

Code metrics help quantify how maintainable, complex, and testable your code is. Visual Studio provides these metrics via:

Analyze → Analyze Code Metrics

🖼️ Image: Visual Studio Code Metrics Panel

A screenshot of Visual Studio’s Code Metrics results showing Maintainability Index, Cyclomatic Complexity, etc.

Code Metrics Explained

Here’s what each metric means and why it matters:

1. Maintainability Index (MI)

Definition: A numeric score (0–100) indicating how easy it is to maintain a code element.
✅ 80–100: Easy to maintain
⚠️ 50–79: Moderate
❌ 0–49: Hard to maintain

2. Cyclomatic Complexity (CC)

Definition: The number of independent paths through the code. Increases with if, switch, for, etc.
✅ <10: Simple
⚠️ 10–20: Moderate
❌ >20: Complex

3. Depth of Inheritance

Definition: The number of class levels above the current class in the hierarchy.
✅ 0–3: Ideal
❌ >4: May be problematic

4. Class Coupling

Definition: Number of external classes/types referenced.
✅ <10: Low coupling (preferred)
❌ >20: High coupling (bad for maintainability)

5. Lines of Executable Code

Definition: Number of actual executable lines of code (ignores comments/braces).
✅ <200 per class, <50 per method
❌ >500: Too complex, consider breaking apart

🖼️ Image: Metric Definitions Heatmap Table

A visual summary showing good, warning, and bad ranges for each metric (green-yellow-red).

Code Metrics Review Checklist

Here’s a handy checklist to evaluate your API controllers or classes:

MI < 50? Refactor needed!
CC > 10? Simplify or extract methods.
Inheritance depth > 3? Consider flattening it.
Class coupling > 10? Break dependencies, inject interfaces.
Too many LOC? Break into smaller classes/services.

Real-Life Example: Refactoring a Bloated API Controller

Let’s say you have this OrdersController. Everything works, but the code smells.

public class OrdersController : ControllerBase
{
    [HttpPost]
    public async Task<IActionResult> CreateOrder(OrderDto dto)
    {
        if (dto == null || dto.Items.Count == 0)
            return BadRequest("Invalid order");

        var customer = await _context.Customers.FindAsync(dto.CustomerId);
        if (customer == null)
            return NotFound("Customer not found");

        var order = new Order
        {
            CustomerId = dto.CustomerId,
            CreatedAt = DateTime.UtcNow,
            Items = dto.Items.Select(x => new OrderItem
            {
                ProductId = x.ProductId,
                Quantity = x.Quantity,
                Price = x.Price
            }).ToList()
        };

        _context.Orders.Add(order);
        await _context.SaveChangesAsync();

        _logger.LogInformation($"Order {order.Id} created");

        return Ok(order.Id);
    }
}

🖼️ Image: OrdersController Before Refactor

Highlight that business logic, DB operations, and validation are all mixed in the controller.

Code Metrics Report

Metric	Value	Issue
Maintainability Index	47 ❌	Too low
Cyclomatic Complexity	15 ⚠️	Too many branches
Class Coupling	12 ⚠️	High dependencies
Executable LOC	80 ⚠️	Too much logic in one method

Refactoring Plan

We move logic to a new OrderService.

public class OrderService : IOrderService
{
    public async Task<int> CreateOrderAsync(OrderDto dto)
    {
        var customer = await _context.Customers.FindAsync(dto.CustomerId)
                      ?? throw new Exception("Customer not found");

        var order = new Order
        {
            CustomerId = dto.CustomerId,
            CreatedAt = DateTime.UtcNow,
            Items = dto.Items.Select(x => new OrderItem
            {
                ProductId = x.ProductId,
                Quantity = x.Quantity,
                Price = x.Price
            }).ToList()
        };

        _context.Orders.Add(order);
        await _context.SaveChangesAsync();
        _logger.LogInformation($"Order {order.Id} created");

        return order.Id;
    }
}

Updated controller:

[HttpPost]
public async Task<IActionResult> CreateOrder(OrderDto dto)
{
    try
    {
        var orderId = await _orderService.CreateOrderAsync(dto);
        return Ok(orderId);
    }
    catch (Exception ex)
    {
        _logger.LogError(ex, "Error creating order");
        return BadRequest(ex.Message);
    }
}

🖼️ Image: Refactored Architecture Diagram

Show controller → service → dbContext pattern (clean layering).

After Refactoring Metrics

Metric	Value	Improvement
Maintainability Index	90 ✅	Big boost
Cyclomatic Complexity	3 ✅	Clean logic
Class Coupling	4 ✅	Reduced
Executable LOC	20 ✅	Much leaner

🖼️ Image: Before vs After Metrics Bar Chart

Visual comparison of metric values before and after refactoring.

Lessons Learned

Metrics are not just numbers—they’re clues to identify code smells.
Refactoring based on metrics leads to better testability, scalability, and developer happiness.
Good architecture grows from clean, measurable decisions.

Bonus: Automate It in CI/CD

You can integrate metrics analysis into your DevOps pipeline using:

🔍 Roslyn Analyzers
🧠 NDepend
🌊 SonarQube
🛠️ dotnet code-quality tools

🖼️ Image: CI/CD Quality Gate Flowchart

Show code → build → analyze → quality gate → deploy.

🧾 Final Thoughts

Taking time to analyze and improve code complexity today will save you countless hours of debugging and scaling pain tomorrow. Start small—run metrics on one class per sprint.

🔁 Refactor. 🔬 Measure. ✅ Repeat.

💬 How do you manage complexity in your .NET projects? Share your tips below!

✍️ Written by Rupinder Kaur, a Senior .NET Developer passionate about clean architecture, refactoring, and continuous improvement.

Simplify Your .NET Codebase: A Guide to Code Metrics and Controller Refactoring

Rupinder Kaur — Thu, 24 Jul 2025 19:10:39 +0000

In this post, I’ll walk you through:

What each code metric means
How to use them to identify messy code
A real-life example of refactoring a bloated API controller
A checklist to guide your review process

Let’s dive in!

What Are Code Metrics?

Code metrics help quantify how maintainable, complex, and testable your code is. Visual Studio provides these metrics via:

Analyze → Analyze Code Metrics

Code Metrics Explained

Here’s what each metric means and why it matters:

1. Maintainability Index (MI)

Definition: A numeric score (0–100) indicating how easy it is to maintain a code element.
✅ 80–100: Easy to maintain
⚠️ 50–79: Moderate
❌ 0–49: Hard to maintain

2. Cyclomatic Complexity (CC)

Definition: The number of independent paths through the code. Increases with if, switch, for, etc.
✅ <10: Simple
⚠️ 10–20: Moderate
❌ >20: Complex

3. Depth of Inheritance

Definition: The number of class levels above the current class in the hierarchy.
✅ 0–3: Ideal
❌ >4: May be problematic

4. Class Coupling

Definition: Number of external classes/types referenced.
✅ <10: Low coupling (preferred)
❌ >20: High coupling (bad for maintainability)

5. Lines of Executable Code

Definition: Number of actual executable lines of code (ignores comments/braces).
✅ <200 per class, <50 per method
❌ >500: Too complex, consider breaking apart

Code Metrics Review Checklist

Here’s a handy checklist to evaluate your API controllers or classes:

MI < 50? Refactor needed!
CC > 10? Simplify or extract methods.
Inheritance depth > 3? Consider flattening it.
Class coupling > 10? Break dependencies, inject interfaces.
Too many LOC? Break into smaller classes/services.

Real-Life Example: Refactoring a Bloated API Controller

Let’s say you have this OrdersController. Everything works, but the code smells.

public class OrdersController : ControllerBase
{
    [HttpPost]
    public async Task<IActionResult> CreateOrder(OrderDto dto)
    {
        if (dto == null || dto.Items.Count == 0)
            return BadRequest("Invalid order");

        var customer = await _context.Customers.FindAsync(dto.CustomerId);
        if (customer == null)
            return NotFound("Customer not found");

        var order = new Order
        {
            CustomerId = dto.CustomerId,
            CreatedAt = DateTime.UtcNow,
            Items = dto.Items.Select(x => new OrderItem
            {
                ProductId = x.ProductId,
                Quantity = x.Quantity,
                Price = x.Price
            }).ToList()
        };

        _context.Orders.Add(order);
        await _context.SaveChangesAsync();

        _logger.LogInformation($"Order {order.Id} created");

        return Ok(order.Id);
    }
}

Code Metrics Report

Metric	Value	Issue
Maintainability Index	47 ❌	Too low
Cyclomatic Complexity	15 ⚠️	Too many branches
Class Coupling	12 ⚠️	High dependencies
Executable LOC	80 ⚠️	Too much logic in one method

Refactoring Plan

We move logic to a new OrderService.

public class OrderService : IOrderService
{
    public async Task<int> CreateOrderAsync(OrderDto dto)
    {
        var customer = await _context.Customers.FindAsync(dto.CustomerId)
                      ?? throw new Exception("Customer not found");

        var order = new Order
        {
            CustomerId = dto.CustomerId,
            CreatedAt = DateTime.UtcNow,
            Items = dto.Items.Select(x => new OrderItem
            {
                ProductId = x.ProductId,
                Quantity = x.Quantity,
                Price = x.Price
            }).ToList()
        };

        _context.Orders.Add(order);
        await _context.SaveChangesAsync();
        _logger.LogInformation($"Order {order.Id} created");

        return order.Id;
    }
}

Updated controller:

[HttpPost]
public async Task<IActionResult> CreateOrder(OrderDto dto)
{
    try
    {
        var orderId = await _orderService.CreateOrderAsync(dto);
        return Ok(orderId);
    }
    catch (Exception ex)
    {
        _logger.LogError(ex, "Error creating order");
        return BadRequest(ex.Message);
    }
}

After Refactoring Metrics

Metric	Value	Improvement
Maintainability Index	90 ✅	Big boost
Cyclomatic Complexity	3 ✅	Clean logic
Class Coupling	4 ✅	Reduced
Executable LOC	20 ✅	Much leaner

Lessons Learned

Metrics are not just numbers—they’re clues to identify code smells.
Refactoring based on metrics leads to better testability, scalability, and developer happiness.
Good architecture grows from clean, measurable decisions.

Bonus: Automate It in CI/CD

You can integrate metrics analysis into your DevOps pipeline using:

Roslyn Analyzers
NDepend
SonarQube
dotnet code-quality tools

Final Thoughts

Taking time to analyze and improve code complexity today will save you countless hours of debugging and scaling pain tomorrow. Start small—run metrics on one class per sprint.

🔁 Refactor. 🔬 Measure. ✅ Repeat.

💬 How do you manage complexity in your .NET projects? Share your tips below!

Demystifying SQL Indexes: A Beginner-to-Advanced Guide with Real-Life Examples

Rupinder Kaur — Thu, 03 Jul 2025 20:22:08 +0000

Master the art of SQL indexes — from the ground up — using real-world analogies, visuals, and hands-on insights.

If you're a developer, data analyst, or DBA who's ever asked:

“Why is this query so slow?”

Chances are... you’re missing the right index.

In this post, we’ll walk through SQL indexes from scratch, building up to best practices, types of indexes, query performance plans, and even real-life cases using the Query Store.

What is an Index (in plain English)?

Think of an index as a book's table of contents.

If you want to find "Chapter 9: Advanced SQL", would you flip every page? No way. You’d look at the index, find the page number, and jump right to it.

💡 In SQL, an index is a lookup mechanism that helps the database find rows faster without scanning the entire table.

Without vs With Index: Real-Life Query Example

-- Without index: SQL scans entire table
SELECT * FROM books WHERE author = 'J.K. Rowling';

-- With index on author column: SQL does a fast lookup
CREATE NONCLUSTERED INDEX idx_books_author ON books(author);

Types of SQL Indexes (with Examples)

Index Type	Description	SQL Example
Clustered Index	Sorts the actual table data	(Usually on the primary key)
Non-Clustered Index	Creates a separate lookup structure	`CREATE NONCLUSTERED INDEX idx_title ON books(title);`
Composite Index	Index on multiple columns	`CREATE INDEX idx_author_genre ON books(author, genre);`
Unique Index	Ensures column values are unique	`CREATE UNIQUE INDEX idx_unique_email ON users(email);`
Filtered Index	Applies to rows that meet a condition	`CREATE INDEX idx_active_books ON books(status) WHERE status = 'Available';`
Full-Text Index	For keyword searches on text	Useful in search engines or blogs
XML / Spatial Index	For XML and geospatial data	Special use cases

Index in Action: Clustered Index Scan vs Seek

Use SQL Server’s Execution Plan to understand if your query is using indexes correctly.

Index Seek = Fast, precise lookup ✅
Index Scan = Scans part or full index ❌
Clustered Index Scan = Scans entire table ❌❌

👉 Use Ctrl+M in SSMS before executing your query to see the plan.

Example:

SELECT * FROM books WHERE author = 'J.K. Rowling';

With index on author: Index Seek
Without index: Clustered Index Scan (slow)

Tools to Analyze Index Usage

Tool	What It Does
Execution Plan Viewer (SSMS)	Shows scans/seeks and cost
`sp_helpindex 'table'`	Lists all indexes on a table
`sys.dm_db_index_usage_stats`	Tracks index usage metrics
Query Store	Captures performance history, regressions, and lets you force good plans

Query Store Real-Life Scenario: Regressed Query

Imagine this scenario in your e-commerce app:

Week 1:

SELECT title FROM books WHERE author = 'J.K. Rowling';
-- Fast: Index Seek used

Week 3:

Same query, but now...

⚠️ Suddenly runs slower. Why?

SQL may have changed the execution plan.

Use Query Store → Regressed Queries in SSMS to find that the plan regressed from Seek → Scan.

🎯 Fix: Add or rebuild index, or force the old (faster) plan from Query Store.

When Should You Create an Index?

Ask these questions:

Does this column appear frequently in WHERE, JOIN, or ORDER BY?
Is the query slow without an index? (Check execution plan!)
Are you doing point lookups or range queries?
Does the table have millions of rows?

Don’t index:

Columns with very low cardinality (e.g., status = 'Active')
Frequently updated columns (high write cost)
Too many indexes (every insert/update/delete becomes expensive)

Pro Tips for Index Design

Tip	Why It Matters
Always analyze with the Execution Plan	Confirm if index is used
Use composite indexes when filtering on multiple columns	E.g., `WHERE author = 'A' AND genre = 'B'`
Don’t blindly create indexes	Use `sys.dm_db_index_usage_stats` to see if they’re used
Clean up unused indexes	They slow down DML (Insert/Update/Delete)
Use Query Store to spot regressions or force good plans	Especially after deployments or data growth

BONUS: How to Test Index Performance

-- Optionally recompile to avoid cached plan
SELECT * FROM books WHERE author = 'Agatha Christie'
OPTION (RECOMPILE);

Then use:

Execution Plan: Clustered Scan vs Seek
Query Store: See duration trend over time
Index usage stats DMV

Conclusion: Indexing Isn’t Magic — It’s Smart Design

You don’t need to memorize syntax — you need to understand the principles:

How SQL searches data
How indexes accelerate or hinder performance
How to analyze and tune your queries like a pro

If you design indexes intentionally — and test them properly — you’ll unlock blazing fast SQL performance and become your team’s database hero.

📢 If you found this helpful:

💬 Drop a comment
🧵 Follow me here on Dev.to and LinkedIn

Hosting Your ASP.NET Core MVC App on Azure for Free

Rupinder Kaur — Fri, 27 Jun 2025 13:30:12 +0000

Introduction

Whenever you're building an application that requires authentication, you might wonder how to host it online - especially without incurring costs. One powerful way to achieve this is by deploying it to a cloud platform like Azure.

This post walks you through how to host your ASP.NET Core MVC application on Azure's Free App Service Tier using GitHub for CI/CD, secure app settings, and modern cloud tools - all at zero cost.

Whether you're building a portfolio, side project, or want production-ready experience, this guide will get you there step-by-step.

Step 1: Prerequisites

Before we get started:

ASP.NET Core MVC app with Identity & Tailwind
Visual Studio 2022+ or VS Code
.NET SDK 7 or later
GitHub account (with repo for your app)
Azure account (Free Tier: https://azure.microsoft.com/free)

Step 2: Prepare Your App for Azure Deployment

Clean up and prepare your app:

Remove debug/seed-only code
Add appsettings.Production.json for logs, etc.
Store secrets using dotnet user-secrets

Example:

dotnet user-secrets set "Authentication:Google:ClientId" "your-client-id"

dotnet user-secrets set "Authentication:Google:ClientSecret" "your-client-secret"

Run a local publish to confirm it’s build-ready:

dotnet publish -c Release

Step 3: Set Up Azure App Service

Go to Azure Portal → Create Resource → App Service
Fill required fields:

Field	Value
Name	expenseManagement-yourname
Stack	.NET 7 or later
OS	Linux or Windows
Region	your closest location
Plan	F1 (Free Tier)

Click “Create” and wait for deployment to complete.

Step 4: Connect to GitHub for Continuous Deployment

Go to Azure Portal → App Service → Deployment Center and fill the below information:

Source: GitHub
Build: GitHub Actions
Repo: your project
Branch: main or master

This auto-generates a GitHub Actions YAML file that builds and deploys on every push!

Step 5: Configure App Settings & Secrets in Azure

In Azure → App Service → Configuration:

Name	Value
Authentication:Google:ClientId	your-client-id
Authentication:Google:ClientSecret	your-client-secret
ConnectionStrings:DefaultConnection	SQL Server conn string (if used)
ASPNETCORE_ENVIRONMENT	Production

After saving, restart the app to apply changes.

Step 6: Test Your Deployed App Live

Your site is now live at:

https://your-app-name.azurewebsites.net

Test:

UI, navigation, Tailwind styles
OAuth login (Google)
Identity and user creation
DB entries & logs

Conclusion & What's Next

Congratulations! 🎉 Your ASP.NET Core MVC app is now hosted in the cloud - securely and for free.

You've learned how to:

Deploy to Azure's Free App Service Tier
Connect CI/CD with GitHub Actions
Secure secrets using App Settings
Push real projects live to the web

📢 If you found this helpful:

💬 Drop a comment
🧵 Follow me here on Dev.to and LinkedIn

Secure .NET App with Google Authentication (Step-by-Step)

Rupinder Kaur — Fri, 20 Jun 2025 16:55:33 +0000

When building a web app with login functionality, you’ll often wonder how to handle authentication securely and efficiently. External login providers like Google, Facebook, and LinkedIn offer users a seamless and trusted sign-in experience. Integrating Google login enhances security via OAuth 2.0 and saves you from managing passwords. It also improves usability by letting users log in with accounts they already use.

This guide walks you through adding Google authentication to your ASP.NET Core MVC app step by step.

Step 1: Create an ASP.NET Core MVC Project with Identity

Let’s start by creating the ASP.NET Core MVC application that we’ll be working with.

Follow these steps using Visual Studio:

Open Visual Studio 2022 or later.
Click on Create a new project.
In the project template list, select ASP.NET Core Web App (Model-View-Controller). 👉 Tip: You can search “mvc” in the search box to find it quickly.
Click Next.
Give your project a name, such as JobTracker or JobApplicationPortal.
Choose a location on your computer where the project should be saved, then click Next.
On the Additional Information screen:
- Target Framework: .NET 7 or later
- Authentication Type: Individual Accounts
- Ensure Configure for HTTPS is checked
Click Create.

Once the project is created, run it using Ctrl + F5. You should see a default ASP.NET Core MVC homepage with Register and Login links — this means Identity is successfully configured.

✅ Great! Now that your project is set up, let’s move on to installing the required packages to support Google login.

Step 2: Install Required NuGet Packages

To enable Google login, first install the necessary authentication packages:

Install-Package Microsoft.AspNetCore.Authentication.Google

Also ensure you already have:

Install-Package Microsoft.AspNetCore.Identity.EntityFrameworkCore
Install-Package Microsoft.AspNetCore.Identity.UI
Install-Package Microsoft.EntityFrameworkCore.SqlServer
Install-Package Microsoft.EntityFrameworkCore.Tools

💡 These enable ASP.NET Identity, EF Core, and Google OAuth integration.

Step 3: Create Google OAuth Credentials

Head to Google Cloud Console:

Create a new project
Enable "Google Identity Services" API
Go to "OAuth consent screen" → External → Fill app info → Add localhost as authorized domain
Create OAuth credentials
- App type: Web
- Redirect URI: https://localhost:7020/signin-google
Store your client ID/secret securely using these steps:
- Open Visual Studio.
- Right-click your project in Solution Explorer and select Open in Terminal (or use Command Prompt/PowerShell).
- Make sure you're in the folder where your .csproj file is located.
- Run the following command to initialize user secrets if you haven’t already:

dotnet user-secrets init

Store your client ID/secret securely using:

dotnet user-secrets set "Authentication:Google:ClientId" "your-client-id"
dotnet user-secrets set "Authentication:Google:ClientSecret" "your-client-secret"

Step 4: Configure Google Auth in Program.cs

Inside Program.cs, add Google auth after setting up Identity:

builder.Services.AddAuthentication()
    .AddGoogle(options =>
    {
        options.ClientId = builder.Configuration["Authentication:Google:ClientId"];
        options.ClientSecret = builder.Configuration["Authentication:Google:ClientSecret"];
    });

Step 5: Add Google Login Button in UI

In Areas/Identity/Pages/Account/Login.cshtml, below your login form, add:

<div class="mt-6 border-t pt-4">
  <p class="text-sm text-center text-gray-500 mb-4">Or sign in with</p>
  <form asp-page="./ExternalLogin" asp-route-provider="Google" method="post" class="w-full">
    <input type="hidden" name="returnUrl" value="@Model.ReturnUrl" />
    <button type="submit" class="w-full py-2 px-4 bg-red-600 text-white rounded hover:bg-red-700">
      Continue with Google
    </button>
  </form>
</div>

Step 6: Test the Login Flow

Run your app → go to /Identity/Account/Login
Click the Google button → authenticate via Google
Redirected back to /signin-google
ASP.NET Core Identity creates the user if it doesn't exist
Check AspNetUsers and AspNetUserLogins tables in your DB.

Conclusion & What’s Next

Congrats! 🎉 You added Google login to your ASP.NET Core MVC app.

You now understand:

How to connect Google OAuth to .NET Identity
How to secure credentials using User Secrets

📢 If you found this helpful:

💬 Drop a comment
🧵 Follow me here on Dev.to and LinkedIn

Let’s keep building real projects together!