Transition from web.config to appsettings about systemweb-adapters

[twsouthwick]

Some APIs that may be related here:

• HttpContext.GetSection
• HttpContext.GetGlobalResourceObject
• HttpContext.GetLocalResourceObject

[twsouthwick]

While thinking about this some more, I realized an additional challenge. Users will most likely be using System.Configuration.ConfigurationManager.AppSettings to grab the values throughout the code. This makes anything to use Microsoft.Extensions.Configuration more work in the migration process and potentially difficult to update all the code.

In order to help, we may want to initially ensure that the values from web.config show up in AppSettings - this moves the migration for configuration after they have successfully moved to core. I have a prototype of this in https://github.com/dotnet/systemweb-adapters/tree/tasou/web-config that adds some msbuild logic. This is needed because web.config as-is from a framework application will have configuration sections that are unknown to .NET Core which will cause a runtime exception. To mitigate this, the prototype does the following:

• When adding Microsoft.AspNetCore.SystemWebAdapters.CoreServices, some msbuild targets will be injected into their project
• These tasks search for any web.config entries
• An XSL transformation is performed on the supplied web.config that will keep just the AppSettings/ConnectionStrings
• The final web.config is placed next to the output with the name of [ProjectName].dll.config so that the configuration manager will pick it up.

Some open questions:

• ConfigurationManager only appears to read the settings automatically if the name is [ProjectName].[exe|dll|.config. If that's the case, we may need to merge with any existing config
• We'd probably want to help people move off of it - maybe adding an analyzer that flags usage of ConfigruationManager.[AppSettings|ConnectionStrings] and pushes people to the optinos pattern

[joperezr]

We talked about this one today to see if it should be considered. It is unclear if a) this problem is common enough were we want to provide a solution, and b) if this is the right approach to addressing this as opposed to having aspnetcore be able to understand web.config. @twsouthwick will follow up on this.