Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[release/3.1] Tools: Fix up App.config path on .NET Framework #21272

Merged
merged 1 commit into from
Jul 15, 2020
Merged

[release/3.1] Tools: Fix up App.config path on .NET Framework #21272

merged 1 commit into from
Jul 15, 2020

Conversation

bricelam
Copy link
Contributor

@bricelam bricelam commented Jun 15, 2020

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 command Update-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 not System.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.

@bricelam bricelam requested a review from ajcvickers June 15, 2020 16:58
@ajcvickers
Copy link
Member

@bricelam If you're confident the fix is safe, then I'll take it to Tactics. It does make sense to fix this in 3.1 where .NET Framework is still supported.

@bricelam bricelam added this to the 3.1.6 milestone Jun 15, 2020
@ajcvickers ajcvickers modified the milestones: 3.1.6, 3.1.x Jun 16, 2020
@leecow leecow modified the milestones: 3.1.x, 3.1.7 Jun 16, 2020
@ajcvickers
Copy link
Member

@bricelam Approved by Tactics for 3.1.7.

@bricelam
Copy link
Contributor Author

Blocked waiting for branch to open.

@jklaus
Copy link

jklaus commented Jun 22, 2020

Nudge

@ajcvickers
Copy link
Member

@jklaus This is approved for 3.1.7. It now needs to go through the patch build and validation process, which will start soon.

@jklaus
Copy link

jklaus commented Jun 24, 2020

@ajcvickers Thanks for the update.

@bricelam bricelam removed the blocked label Jul 14, 2020
@bricelam bricelam merged commit bbe1a69 into dotnet:release/3.1 Jul 15, 2020
@bricelam bricelam deleted the config branch July 15, 2020 00:27
@ajcvickers ajcvickers removed this from the 3.1.7 milestone Dec 11, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants