问为什么web.config是在发布时创建的，而不是在Asp.Net核心API中构建项目时创建的？

EN

据我所知，web.config用于告诉IIS如何使用asp.net核心模块和处理程序来承载asp.net核心应用程序。在VS中构建和测试应用程序时，不需要创建web.config，因为它将读取launchSettings.json而不是web.config。

Web.config是一个服务器配置文件，用于配置ASP.NET核心模块。

web.config文件可以提供控制活动IIS模块的附加IIS配置设置。有关能够使用ASP.NET核心应用程序处理请求的IIS模块的信息，请参阅IIS模块主题。

Asp.net核心web.config内容(没有这个文件，我们就无法直接在IIS上托管asp.net核心应用程序)

<?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>

IIS需要运行在那里的应用程序的web.config文件。

在ASP.NET核心中，web.config是延迟生成的。假设(有缺陷，IMO)在准备发布到IIS之前不需要web.config。但是，如果您的IIS应用程序指向您的本地代码实例，这样您就不必每次进行代码更改并希望在IIS中测试应用程序时重新发布应用程序，该怎么办？或者，如果像OP一样，您想要使用备用的部署方法呢？

在这种情况下，解决办法是发布应用程序一次，获取生成的web.config，并将其复制到VS项目的根目录(与bin文件夹相同的级别)。随后的构建将将web.config复制到bin\debug\net6.0。仍然不理想，但这比手动创建web.config和可能在文件中引入错误要好。