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

Design tools unable create DbContext with custom constructor using the services provider #17273

Merged
merged 2 commits into from
Jan 29, 2020
Merged

Design tools unable create DbContext with custom constructor using the services provider #17273

merged 2 commits into from
Jan 29, 2020

Conversation

VladDragnea
Copy link
Contributor

I've noticed that design time tools cannot instantiate a DbContext if the constructors doesn't follow a standard pattern (default constructor or with DbContextOptions derived parameter), even if the service provider is able to create the context.
The proposed change only replace:

Activator.CreateInstance(...);

with:

ActivatorUtilities.GetServiceOrCreateInstance(...);

which I think it will fallback to the previous behavior if the service provider is unable to create the context.
A test for checking this scenario has been added.

@dnfclas
Copy link

dnfclas commented Aug 20, 2019

CLA assistant check
All CLA requirements met.

@bricelam
Copy link
Contributor

bricelam commented Aug 20, 2019

This will only help when your DbContext isn't registered as a service (e.g. via AddDbContext) but has a constructor that takes services. Is that the scenario you're trying to enable?

@bricelam bricelam self-assigned this Aug 20, 2019
@VladDragnea
Copy link
Contributor Author

Yes, but not only that. I could also happen when my DbContext is registered as a service, but not via AddDbContext. For example a context with a single constructor that takes a connection string, registered as a service with a factory. It will be provided by the service provider but not discoverable, because the code that looks for it actually looks for DbContextOptions.

@ajcvickers
Copy link
Member

@VladDragnea If you have a single constructor taking the connection string, then how will the context created using ActivatorUtilities get the correct connection string?

@VladDragnea
Copy link
Contributor Author

@ajcvickers the parameters, whichever they are, could be provided by the factory that is registered with the service provider. I've simulated this situation in the test case with a dummy connection string.

@ajcvickers
Copy link
Member

Notes from triage: we will take this for the release aligned with .NET 5. (Note that no new features are allowed in 3.1 without director-level approval.)

@bricelam bricelam added this to the 5.0.0 milestone Oct 25, 2019
@bricelam
Copy link
Contributor

Made a few tweaks:

  • Handled the different exception type thrown by ActivatorUtilities
  • Merged your test into our existing DbContextOperations tests and changed it into a more real-world scenario

@bricelam bricelam removed this from the 5.0.0 milestone Jan 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants