autogenerate bindingRedirects using configSection or fully autogenerate web.config allowing it to be added it to .gitignore
There are various issues with web.config being committed. For the most part, various configuration which can be automatically generated or depends on external factors currently goes into web.config and the user is required to commit web.config. It would be much easier if it were built and it were possible to place the built web.config or the built portion of the web.config into .gitignore while committing the non-generated portion.
One common issue with web.config is that any project using it cannot benefit from automatic `<bindingRedirect/>` generation. Binding redirects must be written manually by the user or by VisualStudio when clicking on the error message. Then these changes must be committed. This makes consuming NuGet packages much harder, especially if using PackageReference and floating versions. The automatic `<bindingRedirect/>` support only works if the project’s app.config (which web.config acts as) can be fully automatically generated.
In web.config, there is a place to put the `<appSettings/>` and `<connectionStrings/>` elements. These often need to be customized by each individual developer for their particular machine and development environment. For example, the developer may have multiple instances of SQL Server and need to specify the correct instance name which would be different from the instance name used by another developer working on the same project on another machine. There already are multiple mechanisms to allow these elements to be configured from an external file which can be excluded from the VCS: ConfigSource https://docs.microsoft.com/dotnet/api/system.configuration.sectioninformation.configsource?view=netframework-4.7.2 and, specific to appSettings, the merge-supporting file: https://docs.microsoft.com/dotnet/api/system.configuration.appsettingssection.file?view=netframework-4.7.2 . However, the default Visual Studio tools and GUIs and functionality do not 1. make use of configSection for autogeneratable sections such as `<bindingRedirect/>`. 2. Do not provide a good out-of-the box project setup which supports interpolating the committable portion of appSettings and connectionString (e.g., connection strings for use in a Release build meant to be sent to production) (e.g., some appSettings might be intended to be constant because it is, e.g., used to configure EntityFramework or set or unset a package’s compatibility flag instead of being something the developer would customize for their system).
I feel like I have to do a lot of work to work around the fact that web.config must be committed to the VCS and yet, by default, is the only place where certain configuration changes, which are often specific to my system, can be made. This should be part of the out of box experience with a new ASP.NET project of any kind.