ASP.NET Core Configuration Masterclass: From Basics to Cloud

In this video, you will learn how to read configuration values from your appsettings.json file using builder.Configuration. We will cover how to extract basic data types like strings, integers, and booleans, as well as how to navigate nested JSON objects using colon notation (for example, "Logging:LogLevel:Default")

Accessing settings as strings can lead to runtime bugs. In this video, you will learn how to use builder.Configuration.GetValue<T>() to automatically convert configuration strings into strongly typed values like int, bool, or custom types. We will also cover how to set default fallback values when a key is missing.

ASP.NET Core provides different methods to navigate nested configurations. In this video, you will learn the exact difference between GetSection(), which isolates a single sub-tree of settings, and GetChildren(), which lets you iterate over a list or collection of configuration nodes.

Writing code to manually read every single property key is slow and error-prone. In this video, you will learn how to map an entire configuration section directly to a C# class. We will compare .Bind(instance) with .Get<T>() using practical side-by-side examples.

Beyond basic class binding, real-world ASP.NET Core apps require fine-grained control over how configuration maps to C# models. In this video, you will explore advanced scenarios using Get<T>() and Bind().

1. Use the [ConfigurationKeyName] attribute to map C# properties to differently named JSON keys.

2. Configure BinderOptions to automatically bind private or internal setters (BindNonPublicProperties).

3. Catch missing or mismatched configuration errors early during startup (ErrorOnUnknownConfiguration).

4. Bind JSON arrays of complex objects into typed C# List<T> and array properties seamlessly.

Ever wondered why your code runs perfectly on your local machine but breaks in staging or production? In this video, you will learn how ASP.NET Core uses ASPNETCORE_ENVIRONMENT to stack environment-specific JSON files over appsettings.json. We will look at file layering order, key overriding rules, and how to test different environments locally using launchSettings.json

Keeping sensitive credentials out of source control

1. Initializing User Secrets via .NET CLI (dotnet user-secrets init).

2. Managing secrets in Visual Studio vs. CLI (dotnet user-secrets set).

3. Physical location of secrets.json on local machines.

4. Automatic enabling of User Secrets during Development environment.

In this video, you will learn how to pass key-value settings directly from the terminal during application startup. We will cover how WebApplication.CreateBuilder(args) automatically parses command-line arguments, how to format nested settings, and why command-line arguments have high priority over other configuration providers.

Typing long configuration keys in the command line can be slow and error-prone. In this video, you will learn how to use Switch Mappings (Dictionary<string, string>) to map short flags (like -p or -db) to full configuration paths. We will build custom mappings and pass them to .AddCommandLine()

Environment variables are essential for cloud deployments and Docker containers. In this video, you will learn how ASP.NET Core loads OS-level environment variables. We will focus on the double-underscore (__) rule, which converts nested JSON keys (like Database:ConnectionString) into compatible environment variable names (Database__ConnectionString).

When multiple configuration sources are used, it can be hard to tell where a specific setting came from. In this video, you will learn how to use builder.Configuration.GetDebugView() to print the complete configuration tree.

In this lecture, you will learn how to use in-memory configuration in ASP.NET Core.

We will cover how to define configuration values directly in code, how to access them through the ASP.NET Core configuration system, and when this approach is useful in real-world applications.

This lesson is part of the complete Configuration in ASP.NET Core course and is designed to help you understand different configuration providers in a simple and practical way.

By the end of this lecture, you will understand:

• What in-memory configuration is

• How to create key-value configuration entries

• How to read configuration values from memory

• Where in-memory configuration fits in ASP.NET Core

In this lecture, you will learn how to control the ASP.NET Core configuration pipeline by clearing the default sources and attaching only the configuration providers you need.

This is an important concept when you want full control over how configuration is loaded in your application.

By the end of this lecture, you will understand:

• How the configuration pipeline works

• How to clear the default configuration sources

• How to add only the required sources

• Why this approach is useful in real applications

In this lecture, you will learn how to use a custom JSON configuration file such as logging.json or xyz.json in ASP.NET Core.

This is useful when you want to separate configuration into multiple files and keep your application settings clean and maintainable.

By the end of this lecture, you will understand:

• How custom JSON configuration files work

• How to add files like logging.json

• Why separate configuration files can be useful

• How custom files fit into the ASP.NET Core configuration system

In this lecture, you will learn how to access a JSON configuration file from a shared class library project in ASP.NET Core.

This approach is helpful when you want to reuse configuration-related logic across multiple projects and keep your solution organized.

By the end of this lecture, you will understand:

• How to read JSON config from a shared class library

• Why shared projects are useful for configuration logic

• How configuration can be reused across applications

• How to structure your solution more cleanly

Ever feel like your configuration code is turning into a mess of string keys and hardcoded values? IOptions<T> is the clean, strongly typed escape hatch.

In this lecture, we take the chaos out of ASP.NET Core configuration and replace it with something far easier to read, maintain, and scale. You’ll see how IOptions<T> lets you bind settings into a class and use them through dependency injection instead of chasing string keys everywhere.

By the end of this lesson, you’ll know:

• why IOptions<T> exists

• how it makes configuration cleaner and safer

• how to bind configuration into a strongly typed model

• how to inject and use options in your application

• why this pattern is a big win for real projects

This is one of those ASP.NET Core features that feels small at first, but once you start using it, you’ll wonder how you ever managed configuration without it.

Your configuration file changes—but should your application really need a restart just to see a new value?

This is the moment IOptionsSnapshot<T> becomes more than another interface to memorize.

In this lecture, you’ll uncover the difference between configuration that stays fixed and configuration that can be refreshed for each new request. You’ll start with the limitation of IOptions<T>, then see how IOptionsSnapshot<T> gives ASP.NET Core a clean, strongly typed way to work with updated settings in scoped services.

More importantly, you’ll understand the boundary: IOptionsSnapshot<T> does not mutate values halfway through an existing request, and it is not something you inject into a singleton. Knowing those details is what separates copying code from understanding the Options pattern.

By the end of this lecture, you’ll be able to:

• explain why IOptions<T> and IOptionsSnapshot<T> behave differently

• configure strongly typed options from an appsettings.json section

• use IOptionsSnapshot<T> inside controllers and scoped services

• understand how configuration reload and request scopes work together

• avoid common service-lifetime mistakes

• choose IOptionsSnapshot<T> confidently in real ASP.NET Core applications

A configuration section name is “just a string”—until you rename the options class and that string quietly becomes wrong.

In this short lesson, you’ll remove one of the most common sources of fragile configuration code: hardcoded section names. You’ll use a section-name property and the nameof operator to make ASP.NET Core options binding safer, clearer, and friendlier to refactoring.

By the end, you’ll know how to:

• avoid repeating configuration section names as raw strings

• use nameof to keep section names aligned with your code

• create a reusable section-name property for an options class

• make options registration easier to maintain as your application grows

It is a small improvement—but exactly the kind that prevents annoying bugs later.

A missing API key. An invalid retry count. An empty connection string.

These are not small configuration mistakes—they are delayed failures waiting to reach production.

In this lesson, you’ll make your ASP.NET Core configuration defend itself. You’ll add validation rules directly to your strongly typed options class with data annotations, enable those rules through ValidateDataAnnotations, and use ValidateOnStart to stop the application immediately when configuration is invalid.

This changes the behavior of your application in an important way: instead of discovering bad settings after a feature runs, a request arrives, or a background service begins processing work, the app refuses to start with unsafe configuration.

By the end of this lesson, you’ll be able to:

• add validation rules to an options class

• use attributes such as Required, Range, and EmailAddress

• enable options validation with ValidateDataAnnotations

• force configuration validation at startup with ValidateOnStart

• understand the difference between validation later and validation at startup

• catch configuration mistakes before they become runtime incidents