Core 3
Core 3
json File
Here I will discuss the ASP.NET Core LaunchSettings.json File with Examples.
The launchSettings.json file in the ASP.NET Core project is a configuration file used to configure various settings
for how the application is launched during development. That means this file contains settings specific to
development environments and is not meant to be used in production. It is located in the Properties folder of our
project. This file is primarily used when running the ASP.NET Core application locally, either through Visual Studio
or using the .NET CLI (Command Line Interface). The following are some of the key primary settings that we are
doing in the launchSettings.json file:
Profiles: Each profile represents a different way to execute the application. Profiles can be set up to
launch the application through IIS Express or directly using Kestrel (the internal web server). Each profile
can specify its own set of environment variables, application URL(s), and other settings.
Application URL: Specifies the URLs the web server will listen on. We can configure multiple URLs by
separating them with a semicolon.
Environment Variables: This includes setting the ASPNETCORE_ENVIRONMENT variable, which can
determine how the application behaves under different environments (e.g., Development, Staging, and
Production). Other environment-specific variables can also be included.
Launch Browser: This setting determines whether a browser should be automatically launched when the
application starts and which URL it should open.
Command Name: Specifies how the application should be launched (e.g., “Project”, “IISExpress”, etc.).
Example to Understand launchSettings.json file in ASP.NET Core:
To understand the ASP.NET Core launchSettings.json file, let u s first create a new ASP.NET Core application with
an empty template. To create a new Empty ASP.NET Core Web Application, open Visual Studio 2022 and click the
Create a new project tab as shown in the image below.
Once you click on the Create a new project box, the “Create a new project” window will open. This window
includes different .NET application templates. Here, we will create a simple Web application from scratch, so
select the ASP.NET Core Empty Project template and then click on the Next button, as shown in the image below.
1
Once you click on the Next button, it will open the following Configure Your New Project window. Here, you
need to provide the necessary information to create a new project. First, give an appropriate name for your
project (FirstCoreWebApplication), set the location where you want to create this project, and the solution name
for the ASP.NET Core Web application. And finally, click on the Next button, as shown in the image below.
Once you click on the Next button, the Additional Information window will open. Here, you need to select .NET 8
as the Framework, check the Configure for HTTPS, Do not use top-level statements check boxes, and finally, click
the Create button, as shown in the image below.
Once you click the Create button, a new ASP.NET Core Web Application will be created in Visual Studio 2022
using .NET 8. The project will have the following file and folder structure.
2
As you can see from the above image, the ASP.NET Core Project has a file called launchSettings.json within the
Properties folder. Let us discuss the need and importance of this file in the ASP.NET Core application.
The most important point to keep in mind is that this launchSettings.json file is only used within the local
development machine. That means it is not required when we publish our ASP.NET Core Application to the
Production Server.
If you have certain settings and want your application to use them when you publish and deploy your ASP.NET
Core Application to the Production Server, you need to store them in the appsettings.json file. Generally, the
configuration settings in the ASP.NET Core application are stored in the appsettings.json file. In our upcoming
article, we will discuss the appsettings.json file in detail.
This file is used to define different profiles (http, https, IIS Express) for running the application in various
environments (like Development, Staging, and Production) and with different configurations (such as using IIS
Express or running directly via the Kestrel server).
If you open the launchSettings.json file, you will find the following code, or settings, within that file in ASP.NET
Core (.NET 8) Applications by default.
{
"$schema": "http://json.schemastore.org/launchsettings.json",
"iisSettings": {
"windowsAuthentication": false,
"anonymousAuthentication": true,
"iisExpress": {
"applicationUrl": "http://localhost:53952",
"sslPort": 44312
}
},
"profiles": {
"http": {
"commandName": "Project",
"dotnetRunMessages": true,
"launchBrowser": true,
"applicationUrl": "http://localhost:5066",
3
"environmentVariables": {
"ASPNETCORE_ENVIRONMENT": "Development"
}
},
"https": {
"commandName": "Project",
"dotnetRunMessages": true,
"launchBrowser": true,
"applicationUrl": "https://localhost:7107;http://localhost:5066",
"environmentVariables": {
"ASPNETCORE_ENVIRONMENT": "Development"
}
},
"IIS Express": {
"commandName": "IISExpress",
"launchBrowser": true,
"environmentVariables": {
"ASPNETCORE_ENVIRONMENT": "Development"
}
}
}
}
Understanding ASP.NET Core LaunchSettings Profiles
Each entry under profiles provides a different way to launch the application. Each profile can specify different
settings like the application URL, environment variables, command line arguments, etc. By default, it comes with
the following three profiles:
Here,
commandName: “Project” indicates that the application should be run directly from the project settings,
bypassing IIS/IIS Express.
launchBrowser: true means the browser will automatically open to the application root URL when the
project is started. The value false means it will not launch the web browser once it hosts the application.
environmentVariables: This is used to set important environment variables during the development
phase. For example, we can set the ASPNETCORE_ENVIRONMENT variable to Development, Staging, or
Production to simulate different environments in our development machine.
4
dotnetRunMessages: true enables messages to be displayed when the project is building using Dot Net
RUN CLI Command in command prompt.
applicationUrl: Specifies the URL where the application is available. In this case, it’s set to
“http://localhost:5066.”
https Launch Profile:
Similar to the “http” profile but includes configurations for both HTTP and HTTPS.
Here,
commandName: “IISExpress” indicates that the application should run under IIS Express, a lightweight,
self-contained version of IIS optimized for development environments.
launchBrowser: Automatically opens the browser to the application URL when the project starts, similar
to other profiles.
Note: The IIS Express profile uses the default IIS Express settings but specifies the environment as
“Development”.
Global Settings
The following are the settings that will be used by the IIS Express profile:
Here,
5
windowsAuthentication: false indicates that Windows Authentication is disabled. This property will
specify whether Windows Authentication is enabled for your application or not. If true means Windows
Authentication is enabled and false means not enabled.
anonymousAuthentication: This property will specify whether anonymous authentication is enabled for
your application. If true, it means anonymous authentication is enabled, and false, it means it is not
enabled.
applicationUrl: “http://localhost:53952” specifies the base URL for the application when running under
IIS Express.
sslPort: 44312 specifies the port to use for SSL traffic (HTTPS) in the case of an IIS Express Server. The
value 0 means you cannot access the application using HTTPS protocol.
Modifying the Main Method of the Program Class
Now, modify the Main Method of the Program class, as shown below, to display the Name of the worker process
that will process the request in the browser window.
namespace FirstCoreWebApplication
{
public class Program
{
public static void Main(string[] args)
{
var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();
app.MapGet("/", () => $"Worker Process Name :
{System.Diagnostics.Process.GetCurrentProcess().ProcessName}");
app.Run();
}
}
}
Case 1: CommandName as HTTP
When we use the command name HTTP to launch our application, then ASP.NET Core will ignore the
AspNetCoreHostingModel value. The Kestrel is the only Web Server that is going to host the application and
process the incoming HTTP requests,
If you look at the launchSettings.json file, you will see that the HTTP profile uses the command name Project.
Also, please focus on the application URL of the HTTP profile. In my case, the URL is http://localhost:5066, and
the port number might vary in your case.
Now, if you run the project either by pressing CTRL + F5 or just F5, then first, it will launch the command prompt,
which will host the application using the Kestrel Web Server, as shown below.
6
Once it launches the command prompt and hosts the application, it opens your default web browser and displays
the worker process name as the project name, i.e., FirstCoreWebApplication, as shown in the image below. This
is because when the CommandName value is Project, it ignores the AspNetCoreHostingModel value, and Kestrel
is the only Web Server that is going to host and process the incoming requests.
Similar to the HTTP Profile, when we use the HTTPS profile to launch our application, it will use the command
name Project and ignore the AspNetCoreHostingModel value. In this case, Kestrel is the only Web Server that will
host and process our application’s incoming HTTP requests.
If you look at the launchSettings.json file, it uses two URLs (https://localhost:7107; http://localhost:5066)
separated by commas. With this profile, you can access the application using both HTTP and HTTPS protocols,
and the port number might vary in your case.
Now, if you run the project with the https profile, it will first launch the command prompt, where it will host the
application using the Kestrel Web Server, as shown below.
Once it launches the command prompt and hosts the application, it opens your default web browser with the
HTTPS protocol and displays the worker process name as the project name, i.e., FirstCoreWebApplication, as
shown in the image below. You can also access the application using the HTTP protocol.
If we use the CommandName as IISExpress Profile and set the AspNetCoreHostingModel value as InProcess in
the application project file, then IIS Express is the only Web Server that will host the application and handle the
7
incoming HTTP requests. Let us prove this. First, modify the application project file as follows. Here, you can see
we are adding the AspNetCoreHostingModel element with the value InProcess.
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>net8.0</TargetFramework>
<Nullable>enable</Nullable>
<ImplicitUsings>enable</ImplicitUsings>
<AspNetCoreHostingModel>InProcess</AspNetCoreHostingModel>
</PropertyGroup>
</Project>
Now, if you look at the IIS Settings, which will be used by the IIS Express profile, you will see that it uses the
53952 port number for HTTP protocol and 44312 for HTTP Protocol. And, if you look at
the launchSettings.json file, you will see that the IIS Express profile uses the “commandName”: “IISExpress”
value.
Now, run the application using the IIS Express profile. Here, you will observe one thing: no command prompt is
opened (as Kestrel Web Server is not used). In this case, IIS Express is the only Web Server that hosts and handles
the application’s incoming HTTP requests. If you look at the browser, it displays the worker process name
as iisexpress.
If we use the CommandName as the IISExpress and set the AspNetCoreHostingModel value as OutOfProcess,
then ASP.NET Core uses IIS Express as the External Web Server to host the application, and Kestrel is the Internal
Web Server to execute our application code.
In this case, the External Web Server, IIS Express, will receive the incoming HTTP Requests from the client and
then forward them to the Internal Web Server, Kestrel, which will process them. Let us prove this. As we already
set the launch profile to IIS Express, we need to change the AspNetCoreHostingModel element value to
OutOfProcess in the application’s project file, as shown below.
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>net8.0</TargetFramework>
<Nullable>enable</Nullable>
<ImplicitUsings>enable</ImplicitUsings>
8
<AspNetCoreHostingModel>OutOfProcess</AspNetCoreHostingModel>
</PropertyGroup>
</Project>
Now, run the application with the IIS Express profile. It should display the project name as the worker process
name, as shown in the image below, as the request is internally processed by the Kestrel Web Server.
To do so, right-click on the project name in Solution Explorer and select the “Properties” option from the context
menu. Once you open the project properties window, click the “Debug” tab, as shown in the image below.
Once you click on the Open debug launch profile UI, the following window will open. You can see that we have
three Launch Profiles here. One is for IIS Express, and the other two (HTTP and HTTPS) are for Kestrel Web
Server. Here, you can also verify and modify the App URL, Hosting Model, Environment Variable, etc., as shown in
the image below.
When we make changes to the launch settings in Visual Studio’s GUI, Visual Studio updates the
launchSettings.json file accordingly. This means that the GUI serves as a convenient way to edit the
9
launchSettings.json file. Since the launchSettings.json file is updated by the GUI, there is no conflict between the
two; they are essentially two interfaces to the same set of configurations.
For example, if we specify an application URL, Hosting Model, or Environment name in both the Visual Studio GUI
and the launchSettings.json file, the actual setting used when you launch the application will be the one reflected
in the launchSettings.json file because the GUI edits this file.
Here I will discuss the use and importance of the ASP.NET Core AppSettings.json File with Examples.
1. What are the Different Configuration Sources Available in the ASP.NET Core application?
2. What is the ASP.NET Core AppSettings.json file?
3. How do we access the configuration information in the ASP.NET Core Application?
4. What is the Configuration Execution Order in ASP.NET Core Application?
5. Real-time Examples of ASP.NET Core AppSettings.json file.
What are the Different Configuration Sources Available in the ASP.NET Core application?
If you have worked with previous versions of the ASP.NET application, you know the importance of the
web.config file. In our traditional ASP.NET application, we generally stored application configuration settings such
as database connection strings, any application-scope global variables, and many more within
the web.config file. But in ASP.NET Core, the application configuration settings can come from different
configuration sources such as:
The appsettings.json file in ASP.NET Core is a JSON-formatted configuration file used to store application-specific
settings configuration data. It provides a structured way to define configuration settings such as database
connection strings, logging options, API keys, and other application-level global parameters needed by the
application that we want to change without recompiling our application.
This file can have environment-specific versions like appsettings.Development.json, appsettings.Staging.json, and
appsettings.Production.json, which are loaded depending on the application’s environment setting. That means
the settings in this file are read at runtime by the Framework and overridden by environment-specific files.
When we create an ASP.NET Core Web Application with the Empty or Razor Pages or MVC or Web API Project
Template, then by default, Visual Studio creates the appsettings.json file for us at the Project root directory as
shown in the below image.
10
If you open the ASP.NET Core appsettings.json file, then you will see the following code by default, which is
created by Visual Studio.
This file is typically divided into sections. For example, we might have sections like ConnectionStrings, Logging, or
custom sections for our application-specific settings. Now, I am going to add a key with the
name MyCustomKey within this file. To do so, please modify the appsettings.json file as shown below. As it is a
JSON file, you need to store the value in the form of a key-value pair.
{
"Logging": {
"LogLevel": {
"Default": "Information",
"Microsoft.AspNetCore": "Warning"
}
},
"AllowedHosts": "*",
"MyCustomKey": "MyCustomKey Value coming from appsettings.json"
}
Logging:
LogLevel: This subsection specifies the minimum log level for different categories of loggers.
1. Default: “Information” – This sets the default log level to Information, meaning logs at the
Information level and above (e.g., Warning, Error, Critical) will be recorded.
2.Microsoft.AspNetCore: “Warning” – This sets the log level specifically for Microsoft.AspNetCore
category to Warning, meaning only warnings, errors, and critical messages will be logged for
components in Microsoft.AspNetCore namespace.
AllowedHosts:
11
The AllowedHosts section specifies which hosts are allowed to make requests to the application. This is typically
used in scenarios where you want to restrict access to certain domains. The “*” wildcard character means that
any host is allowed to access the application. You can restrict it by specifying a comma-separated list of allowed
hostnames, e.g., “example.com, localhost”.
MyCustomKey:
A custom section that we define for our own application settings. “MyCustomKey”: “MyCustomKey Value
coming from appsettings.json”: This is a key-value pair where MyCustomKey is the key, and MyCustomKey Value
coming from appsettings.json is the value. You can retrieve this value in your application code to configure
specific behaviors or settings.
To access configuration settings from the appsettings.json file in ASP.NET Core, we can use the IConfiguration
interface and ConfigurationManager. Let us see how we can access the MyCustomKey value from the
appsettings.json file using our Main method in the Program class. Within the Main method, we will use
ConfigurationManager; from controllers and services, we will use the IConfiguration interface.
Within the Main method, we have the WebApplicationBuilder instance (builder). This instance has the
Configuration property, which will return a ConfigurationManager instance. Using this instance, we can read data
from the appsettings.json file or any other configuration sources, including the environment variables, command
line arguments, etc.
Once we get the ConfigurationManager instance, we can access the Configuration Information from
the appsettings.json file in two ways. They are as follows:
The GetValue<T>(string key) is a generic method that allows us to specify the type to which we want the
configuration value to be converted. Since we specify the type, it ensures that the returned value is of the
specified type. We can also provide a default value as a second parameter. If the key is not found, the method
will return the specified default value instead of throwing an exception or returning null. Here, the second
parameter is optional.
The indexer property ConfigurationManager instance accesses the configuration value directly as a string. It is a
more straightforward way to access the value and is useful for quick and simple string retrieval. The returned
value is always a string, so if you need a different type, you would need to convert it manually.
So, let us modify the Main method of the Program class as follows to access the configuration information from
the appsettings.json file.
namespace FirstCoreWebApplication
{
public class Program
{
public static void Main(string[] args)
12
{
var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();
ConfigurationManager configuration = builder.Configuration;
//Get the Configuration Value using Generic GetValue
//string? MyCustomKeyValue = builder.Configuration.GetValue<string>("MyCustomKey", "DefaultValue");
//Get the Configuration Value using Indexer
string? MyCustomKeyValue = builder.Configuration["MyCustomKey"];
app.MapGet("/", () => $"{MyCustomKeyValue}");
app.Run();
}
}
}
Now run the application, and you should see the value as expected in the browser, as shown in the image below.
Note: The Generic GetValue<T> method is preferred when we need the configuration value in a specific type
other than a string. It ensures type safety and avoids manual conversion. On the other hand, the indexer [“key”]
always returns a string. If we need the value as another type, we need to handle the conversion explicitly. So, for
returning string value, we need to use indexer [“key”], and for other types of values, we need to use the Generic
GetValue<T> method.
Before understanding the execution order, let’s understand the appsettings.Development.json file. As shown in
the image below, you can find this file within your project’s appsettings.json file.
ASP.NET Core supports environment-specific configuration files. This means we can have different versions of
appsettings.json for different environments, like the appsettings.Development.json file for the development
environment, the appsettings.Staging.json file for the Staging environment, and the appsettings.Production.json
file for the Production environment. The appropriate file is loaded based on the environment in which your
application is running so that it can read that environment-specific setting.
13
Modify the appsettings.Development.json File.
To better understand the execution order, let us add the same MyCustomKey to this
appsettings.Development.json file, which we added to the appsettings.json file. So, modify
the appsettings.Development.json file as shown below.
{
"Logging": {
"LogLevel": {
"Default": "Information",
"Microsoft.AspNetCore": "Warning"
}
},
"MyCustomKey": "MyCustomKey Value coming from appsettings.Development.json"
}
As you can see, we are using the same key as in the appsettings.json file but with a different value here. Now, set
the environment to Development within the launchsettings.json file and then run the application, and you should
get the following output.
As you can see from the above output, it fetches the MyCustomKey Value from the
appsettings.Development.json file. I need to make clear that if you have a configuration setting in multiple
configuration sources with the same configuration key, the later configuration sources will override the earlier
configuration sources.
What are the Default Orders for Reading the Configuration Sources in ASP.NET Core?
The default orders in which the various configuration sources are read for the same key are as follows:
1. appsettings.json
2. appsettings.{Environment}.json
3. User Secrets
4. Environment Variables
5. Command-line Arguments
Using Environment Variables
We already have MyCustomKey in two places, i.e., appsettings.json and appsettings.Development.json. Now add
the same key as “MyCustomKey”: “MyCustomKey Value coming from Environment Variable of
LaunchSettings.json” in the IIS Express Profile Section of the LaunchSettings.json file as shown below.
14
With this change, now run the application using the IIS Express launch profile, and it should display the value
coming from the environment variable as shown in the below image.
In Visual Studio, we can easily pass command-line arguments to our ASP.NET Core application using the project
properties. To do so, right-click on your project in the Solution Explorer and select Properties from the context
menu. This opens the project’s properties page.
In the properties window, go to the Debug tab and then click on the Open Debug Launch Profiles UI. Look for a
section named Command line arguments. This field allows you to specify the arguments the application should
receive on startup. Please enter the command line arguments in this field, for example,–MyCustomKey
“MyCustomKey Value coming from Command Line Arguments” as shown in the image below.
Here, –MyCustomKey is the key, and “MyCustomKey Value coming from Command Line Arguments” is the
value we are passing. Click Save on the toolbar or press Ctrl + S to save the settings. As we are setting the
command line arguments for the IIS Express launch profile, so run the application using IIS Express, and you
should see the following output:
The following are some of the real-time examples of how the appsettings.json file can be used in ASP.NET Core
applications:
15
Database Connection Strings:
In this example, a connection string is defined for a database. The application can access this connection string to
interact with the database.
{
"ConnectionStrings": {
"DefaultConnection": "Server=myServerAddress;Database=myDataBase;User
Id=myUsername;Password=myPassword;"
}
}
Logging Configuration
In this example, the logging levels are configured for the application and specific namespaces.
{
"Logging": {
"LogLevel": {
"Default": "Warning",
"Microsoft": "Warning",
"Microsoft.Hosting.Lifetime": "Information"
}
}
}
External Service Configuration
This example shows how to store API settings for external services, like base URLs and API keys.
{
"ExternalService": {
"BaseUrl": "https://api.example.com/",
"ApiKey": "Your-Api-Key-Here"
}
}
Custom Application Settings
Custom settings specific to the application, like page size for pagination or support email addresses.
{
"ApplicationSettings": {
"PageSize": 20,
"SupportEmail": "[email protected]"
}
}
Authentication Settings
16
Settings related to authentication, like JWT settings in this case.
{
"Authentication": {
"Jwt": {
"Key": "Your-Secret-Key",
"Issuer": "YourIssuer",
"Audience": "YourAudience"
}
}
}
API Rate Limiting
{
"RateLimiting": {
"EnableRateLimit": true,
"MaxRequestsPerSecond": 5
}
}
17