In previous article, we have seen how to publish a ASP .NET Core web application to IIS. We have seen that ASP .NET Core Hosting Bundle is required to be installed on the machine where the application needs to be hosted.
In this article, we are going to see how Web.Config
plays role in hosting ASP .NET Core Web Application on IIS.
Web.Config Configuration .NET Core
We already know that web.config
is not used as the configuration file for ASP .NET Core web applications. Those applications now use appsettings.json
, a JSON configuration file.
IIS uses the ASP.NET Core Module to handle the ASP .NET Core application’s requests. The module is an HTTP handler. The handler has some settings which are read by IIS. The handler has settings like processPath
, arguments
, hostingModel
. These settings decide which .NET core application should be invoked and what is the hosting model for the application.
How it works ?
If a web.config file is not present at root, then it is created with the correct processPath
and arguments
during the publish operation.
If a web.config is already present at app’s root, then it is transformed to use correct values for processPath
and arguments
settings and it is copied to published output directory.
For these files, InheritInChildApplications property is set to false to avoid applying these settings to the apps that reside in subdirectory of this app.
Web.Config vs Deployment Modes
Framework-Dependent deployment
generates (or needs) the file as shown below.
<?xml version="1.0" encoding="utf-8"?> <configuration> <location path="." inheritInChildApplications="false"> <system.webServer> <handlers> <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" /> </handlers> <aspNetCore processPath="dotnet" arguments=".\DemoApp.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="inprocess" /> </system.webServer> </location> </configuration>
While, Self-Contained deployment
generates the web.config file as shown below:
<?xml version="1.0" encoding="utf-8"?> <configuration> <location path="." inheritInChildApplications="false"> <system.webServer> <handlers> <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" /> </handlers> <aspNetCore processPath=".\DemoApp.exe" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="inprocess" /> </system.webServer> </location> </configuration>
Impact on Files Served
When an app is published, it contains different kinds of files in Content Root of the site. Below are some files which are present in the published folder.
- {Assembly-Name}.runtimeconfig.json
- {Assembly-Name}.deps.json
- {Assembly-Name}.xml
In above list, {Assembly-Name} is the placeholder for name of assembly.
If a valid web.config file is present at the root, these files would not be served by IIS. Otherwise, these files would be served publicly.
Set Environment Variables
If you want to keep your own web.config
file for your app, you can also set the environment variables via web.config
.
The aspNetCore
element can contain environmentVariables
xml element, where the environment variables can be specified. These values would be applicable to the process specified using processPath
setting.
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?> <configuration> <location path="." inheritInChildApplications="false"> <system.webServer> <handlers> <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" /> </handlers> <aspNetCore processPath="dotnet" arguments=".\DemoApp.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="inprocess"> <environmentVariables> <environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Development" /> <environmentVariable name="CONFIG_DIR" value="f:\application_config" /> </environmentVariables> </aspNetCore> </system.webServer> </location> </configuration>
I hope you find this information is useful.
Javier is Content Specialist and also .NET developer. He writes helpful guides and articles, assist with other marketing and .NET community work