The first one is rather obvious; who doesn't look at the browser output? However, for ASP.NET Core applications, it's far less effective than it used to be, since most errors are still unhandled and won't appear there. Since the application is running in Production mode by default, it will hide--for security reasons--most of the error details. That's a common production-level error message that doesn't tell us anything useful:

In order to get a more useful error message, we need to follow the suggestion printed out at the end of the error page and set up the ASPNETCORE_ENVIRONMENT environment variable--which defaults to Production when not set--to Development instead. We can do that in two ways:

1. On server-level scope, by actually setting a system-wide environment variable, using the Control Panel | System | Advanced Settings | Environment Variables GUI interface.
2. On app-level scope, by altering our web app's Web.config file and overriding that value there.

The latter method is definitely preferable, as it will only change that behavior for our web app, without affecting the whole web server.

Hey, wait a minute! Did we just say "our web app's Web.config file"? What happened to the "no Web.config file required" statement we said back in Chapter 1, Getting Ready?

As a matter of fact, although that's true for the application settings--which are now stored in the appsettings.json files--the Web.config file is still used whenever we host our app with IIS. To say it better, the <system.webServer> section of Web.config is still required to configure most IIS features, regardless of the server-side and client-side technologies we've been using--including those that apply to a reverse proxy configuration such as the one we need to implement.

To understand this better, it can be useful to take a close look at the official docs at https://docs.microsoft.com/en-us/aspnet/core/publishing/iis?tabs=aspnetcore2x , explaining how .NET Core apps are hosted (reverse-proxy between IIS and Kestrel) and how the IIS behavior is still influenced by the Web.config file.