This change will give NET5.0 MSBuild the option to read toolset information from the configuration file ONLY if ToolsetDefinitionLocation is set to 'ConfigurationFile'. Otherwise everything should work the exact same way as before.
This change is beneficial as it allows net5.0 MSBuild to evaluate projects that only net framework MsBuild could before. Since ConfigurationFile wasn't an option in net5.0 before (Due to System.Configuration being only net472), toolsets available to net5.0 MsBuild was minimal, but with this change a net5.0 MsBuild user could specify ConfigurationFile as the ToolsetDefinitionLocation when creating a ProjectCollection and more toolsets would be available depending on the MsBuild.exe provided.
Updated all the System.Configuration references to System.Configuration.ConfigurationManager (Which supports netstandard2.0). This change allows net5.0 to read toolset information from configuration file, but the default remains the same.
Tested locally to make sure the toolset information remains the same for cases other than when ToolsetDefinitionLocation is set to ConfigurationFile. CI should be good enough to ensure everything else still works as before.
Existing unit tests should be good enough to verify that this change does not affect net472 at all. Freed up a lot of unit tests under FEATURE_SYSTEM_CONFIGURATION which can be used to validate that net5.0 behavior without configuration setting works the same as before. Also added in a couple more tests to ensure setting ToolsetDefinitionLocation to ConfigurationFile actually grabs more configurations comparing to default.
…ld into toolsetConfigurationNet5
Yes I think it's fine to add it all the time now. I removed the FEATURE_CONFIGURATION_FILE flags for ToolsetConfigurationReader_Tests and ImportFromExtensionPath_Tests and they both require this file and they both seemed to pass. I believe those are the only 2 occurrences when the file is being used.
Note that a DDRIT test failed in the VS PR, but it doesn't explicitly look like us