[release/3.1] Tools: Fix up App.config path on .NET Framework #21272
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #19760
@ajcvickers Should we
Servicing-consider
this?Description
For EF Core 2.x projects, we use
AppDomainSetup.ConfigurationFile
to specify which *.config file to use at design time.In EF Core 3.0, we removed support for .NET Framework and simplified some design-time hooks since we no longer needed to support our AppDomain strategy for invoking user code.
In EF Core 3.1, we re-added support for .NET Framework but not our AppDomain strategy. Instead, we use a Reflection strategy to invoke user code. There is no API for specifying the *.config file without creating a new AppDomain. (see dotnet/runtime#931)
Customer Impact
APIs used to read the connection string from the *.config file (like
ConfigurationManager
) stopped working at design-time after upgrading to EF Core 3.1. For example, the Migrations commandUpdate-Database
started throwing NullReferenceException.How found
We discussed this limitation as a team prior to releasing EF Core 3.1 and decided it was acceptable given that most EF Core users on .NET Framework were creating ASP.NET Core applications and, thus, using
Microsoft.Extensions.Configuration
and notSystem.Configuration
.Since releasing, several users have hit this limitation and filed issues requesting that we fix it.
Test coverage
Manually verified. Automated testing in this area has been very flakey in the past proving to not be very useful.
Regression?
Yes, from EF Core 2.2 to 3.1. EF Core 3.0 did not support .NET Framework.
Risk
Very low. If the added code fails (e.g. on Mono) execution continues with the same behavior that exists today.