Skip to content

[2.0.0-preview1] Design: Stop invoking Startup.ConfigureServices #8326

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

Merged
merged 1 commit into from
Apr 29, 2017
Merged

Conversation

bricelam
Copy link
Contributor

@bricelam bricelam commented Apr 28, 2017

Part of #8164

Note, this removes to following closure of dependencies form EFCore.Design.

  • System.Globalization.Extensions
  • System.Net.WebSockets
  • System.Reflection.TypeExtensions
  • System.Security.Claims
  • System.Security.Principal
  • System.Text.Encodings.Web
  • Microsoft.AspNetCore.Hosting.Abstractions
  • Microsoft.AspNetCore.Hosting.Server.Abstractions
  • Microsoft.AspNetCore.Http.Abstractions
  • Microsoft.AspNetCore.Http.Features
  • Microsoft.Extensions.FileProviders.Abstractions
  • Microsoft.Extensions.Hosting.Abstractions

Providers: If you're not already implementing IDesignTimeServices in the type pointed to by [DesignTimeProviderServices], you'll need to after this.

@smitpatel
Copy link
Contributor

Correct base branch?

@bricelam
Copy link
Contributor Author

@smitpatel Yes, but only for review... 😉 It's based on #8314

Copy link
Contributor

@ajcvickers ajcvickers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to me. Much better than what we had. Two things:

  • What exception message does the user get if they still have the old-style ConfigureServices app?
  • I still think that given how clean the context factory in the template looks to me, that if Damian is okay with it, then we should only support the context factory going forward. It is very self-documenting and very un-magic.

@bricelam
Copy link
Contributor Author

What exception message does the user get if they still have the old-style ConfigureServices app?

Most will get the typical error:

No parameterless constructor was found on 'ApplicationDbContext'. Either add a parameterless constructor to 'ApplicationDbContext' or add an implementation of 'IDbContextFactory<ApplicationDbContext>' in the same assembly as 'ApplicationDbContext'.

There is a corner case that can happen on the first Add-Migration when your context has been added to the application services, but isn't in either the startup or target project. These advanced users will receive a no context/can't find context error, but the solution is the same--add an IDbContextFactory.

@ajcvickers
Copy link
Contributor

@bricelam Think we need a better message that indicates that this has happened not because they did something "wrong" but because we have made a change in how things work in 2.0. Probably with a fwlink to docs on how to convert. But happy for all this to happen later.

@bricelam bricelam changed the base branch from bricelam/args to rel/2.0.0-preview1 April 29, 2017 02:37
@bricelam bricelam merged commit 3800c68 into dotnet:rel/2.0.0-preview1 Apr 29, 2017
@bricelam bricelam deleted the nhost branch April 29, 2017 02:40
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