If the Web.config file is not present upon the application first run, it will be autogenerated in the root-level folder with the default settings that will best suit the application. In our sample scenario, we should find something like this:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <add name="aspNetCore" path="*" verb="*" 
      modules="AspNetCoreModule" resourceType="Unspecified" />
    </handlers>
    <aspNetCore processPath="dotnet" arguments=".TestMakerFreeWebApp_Chapter_10.dll" stdoutLogEnabled="false" stdoutLogFile=".logsstdout" />
  </system.webServer>
</configuration>

Here's how we can tweak it to set up the ASPNETCORE_ENVIRONMENT environment variable (updated lines are highlighted):

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
    </handlers>
    <aspNetCore processPath="dotnet" 
         arguments=".TestMakerFreeWebApp_Chapter_10.dll" 
         stdoutLogEnabled="false" stdoutLogFile=".logsstdout">
     <environmentVariables>
        <environmentVariable name="ASPNETCORE_ENVIRONMENT" 
            value="Development" />
      </environmentVariables>
  </aspNetCore>
  </system.webServer>
</configuration>

However, performing such change will raise an additional problem in our specific scenario: the Development environment will bring the WebpackDevMiddleware module into action, as clearly stated by our Startup.cs file:

[...]

if (env.IsDevelopment())
{
    app.UseDeveloperExceptionPage();
    app.UseWebpackDevMiddleware(new WebpackDevMiddlewareOptions
    {
        HotModuleReplacement = true
    });
}

[...]

That being the case, the first error we'll receive would be the "failed to start Node process" one, just like in this screenshot:

The best thing we can do to avoid such issue is to rework the middleware loading strategy in the following way (new lines highlighted):

if (env.IsDevelopment())
{
    app.UseDeveloperExceptionPage();
#if DEBUG
    app.UseWebpackDevMiddleware(new WebpackDevMiddlewareOptions
    {
        HotModuleReplacement = true
    });
#endif
}

That way we can set the ASPNETCORE_ENVIRONMENT value to Development and also prevent the WebpackDevMiddleware from being loaded: we should then be able to refresh the home page and retrieve some detailed information regarding our error that will most likely help us understand what's going on.

What to do with this crippled, yet still somewhat required, Web.config file? We can either leave it on the server or keep a copy within our project other files. Those who prefer to keep the IIS configuration separated from the development will probably want to leave on the Web Server; however, our suggestion is to follow the other route and store a copy of that file in our project's root folder, so we'll be able to keep a record of the performed changes we had to do and have them under source control along with the other files: we still feel that this is the better way to deal with it, at least from a Full-stack perspective. Just be sure to rename it with a harmless extension - such as Web.config.IIS - to prevent it from mess with the Development environment.