Why is web.config getting created on publish not on build the project in Asp.Net Core API?

Question

I have Asp.net Core 3.1 API project. When I build it doesn't create any web.config file, but when I publish the API using VS 2019 in a folder, it creates a web.config file. So why it's not creating web.config on build ( I think it should not create because there is no web.config file in the project) but why does it create web.config file on publishing?

Edit: I am trying to deploy the application through Octopus, So I copy the bin folder content, and I need the web.config also. So for time being, I have manually created the web.config in the project and then building the project. so it copies the web.config to the bin folder. So Is this the right approach? or is there any way to generate web.config in the bin folder without manually creating it?

Stigmatic

Related. – Shipowner

Answer 1

As far as I know, the web.config is used to tell IIS about how to use asp.net core module and handler to host the asp.net core application. When you build and test the application in the VS, there is no need to create the web.config, since it will read the launchSettings.json not web.config.

Web.config is a server configuration file, it is used to configures the ASP.NET Core Module.

The web.config file may provide additional IIS configuration settings that control active IIS modules. For information on IIS modules that are capable of processing requests with ASP.NET Core apps, see the IIS modules topic.

Asp.net core web.config content(Without this file, we couldn't directly host the asp.net core application on IIS)

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <location path="." inheritInChildApplications="false">
    <system.webServer>
      <handlers>
        <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
      </handlers>
      <aspNetCore processPath="dotnet" arguments=".\basket.api.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout">
           </aspNetCore>
    </system.webServer>
  </location>
</configuration>

Gyratory

Can we create web.config on build? – Stigmatic

Create your web.config on the root of your project, and Publish will copy that over to the server without creating a new one. – Cruet

Answer 2

You should be using dotnet publish to generate the files that you send to Octopus, not dotnet build. From the documentation:

The dotnet publish command's output is ready for deployment to a hosting system (for example, a server, PC, Mac, laptop) for execution. It's the only officially supported way to prepare the application for deployment.

dotnet publish will determine what is needed based on the inputs you provide, including the runtime identifier (RID). So if you specify, say, a Linux runtime identifier such as linux-x64, dotnet publish will not generate a web.config file. But if you don't specify a runtime identifier, or specify the default value of any, dotnet publish will generate a web.config file, just in case the app happens to be deployed to IIS.

Manhour

Answer 3

IIS requires a web.config file for apps that run there.

In ASP.NET Core, web.config is lazy-generated. The assumption (flawed, IMO) is that you don't need web.config until you are ready to do a true publish to IIS. But what if you have your IIS app pointed to your local code instance so that you don't have to publish your app every time you make a code change and want to test it in IIS? Or what if, like OP, you want to use alternate deployment methods?

A workaround in that case is to publish your app once, take the generated web.config, and copy it to the root of your VS project (same level as the bin folder). Subsequent builds will then copy the web.config to your output folder. Still not ideal, but this is better than manually creating web.config and potentially introducing an error in the file.

If you publish your app as a Web deployment package, the resulting ZIP package will contain a generated web.config you can use.

Aimless