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

donet ef tools: DbContext configuration in WebApp project with DbContext in a class library no longer works in RC2 #5460

Closed
Villason opened this issue May 22, 2016 · 9 comments

Comments

@Villason
Copy link

Villason commented May 22, 2016

My migrations scripts no longer work:

[CmdletBinding()]
Param(
[Parameter(Mandatory=$True)]
  [string]$name
)
dotnet ef migrations add $name -p MySolution.Data.EntityFramework -v 

Error:

Unrecognized option '-p'

My setup is as follows:

MySolution.Web contains the DbContext configuration details like the connection strings.
MySolution.Data.EntityFramework contains my EntityFramework implementation of my data access interfaces. It contains the DbContext and the Migrations in RC1.

What's the proper way to do this now? It appears I can no longer separate the DbContext from its configuration!

@Villason Villason changed the title -p command line option is no longer available DbContext configuration in Web project, DbContext in a class library no longer works in RC2 May 22, 2016
@Villason Villason changed the title DbContext configuration in Web project, DbContext in a class library no longer works in RC2 DbContext configuration in WebApp project with DbContext in a class library no longer works in RC2 May 22, 2016
@Villason
Copy link
Author

I followed this workaround:

https://docs.efproject.net/en/latest/cli/dotnet.html#dotnet-cli-issues

Now the problem is that the class library has no clue about the connection details as those details are in the configuration section of the web project.

No database provider has been configured for this DbContext. A provider can be configured by overriding the DbContext.OnConfiguring method or by using AddDbContext on the application service provider. If AddDbContext is used, then also ensure that your DbContext type accepts a DbContextOptions<TContext> object in its constructor and passes it to the base constructor for DbContext.

I am stuck!

@joeaudette
Copy link

joeaudette commented May 22, 2016

I struggled a bit with the same problem, my ef code is in a class library. I converted it to an app as mentioned in the workaround notes but also added a Program.cs and Startup.cs and appsettings.json and I was able to run the migration from the command line. It may help you to browse my project here https://github.com/joeaudette/cloudscribe/tree/master/src/cloudscribe.Core.Storage.EF

the notes about upgrading from rc1 to rc2 were also helpful https://docs.efproject.net/en/latest/miscellaneous/rc1-rc2-upgrade.html

@Villason
Copy link
Author

Thanks @joeaudette. Basically you created another Web App with just the information the migrations tool uses.

Very dirty!! Hope they fix this soon.

@Villason
Copy link
Author

@joeaudette how will the migrations be performed in production? Does the WebApp know which code to run to apply the latest migrations?

@joeaudette
Copy link

@Villason I'm only generating the migrations from the command line, then they are compiled into the code. Running the migrations happens from the startup of my web app invoking a method here where I am also seeding some data

you can see my web app startup here

though I have not yet tested with multiple migrations, its working fine for me so far with the one initial migration

@Villason Villason changed the title DbContext configuration in WebApp project with DbContext in a class library no longer works in RC2 donet ef tools: DbContext configuration in WebApp project with DbContext in a class library no longer works in RC2 May 22, 2016
@natemcmaster
Copy link
Contributor

This is probably a duplicate of this issue: #5320. It's a known limitation of .NET Core CLI preview 1 and unfortunately something we cannot work around. We depend on them to provide support for running "dotnet ef" on class library projects.

@joeaudette glad you got the workaround we shared to work. You could also use multi-targeting so that you can use dotnet-ef on a class library. cref http://dotnet.github.io/docs/core-concepts/libraries/libraries-with-cli.html#how-to-multitarget

@rowanmiller
Copy link
Contributor

Agreed that this is dupe of #5320 - at the moment we only support everything being in a single project that the command is being executed on.

@kjbetz
Copy link

kjbetz commented May 24, 2016

I was able to get this work a different way. My setup is as described above. A Web app which has the connection string configuration and sets up EF, all Context, model, Entity Framework stuff in a class library. For RC1 the Migrations were stored in the class library too. For RC1 I would call commands like this:

dnx ef migrations add Initial -c MyContext -p MyClassLibProject
dnx ef database update -c MyContext -p MyClassLibProject

When I tried to do this in RC2 I got the above errors. but it suggested:

Your target project 'MyWebApp' doesn't match your migrations assembly 'MyClassLib'.
Either change your target project or change your migrations assembly.
Change your migrations assembly by using DbContextOptionsBuilder. E.g.
options.UseSqlServer(connection, b => b.MigrationsAssembly("MyWebApp")).
By default, the migrations assembly is the assembly containing the DbContext.`

So, I simply did what it said.

services.AddDbContext<MyContext>(options =>
    options.UseSqlServer(Configuration["MyClassLibConfiguration:MyContextConnection"],
        b => b.MigrationsAssembly("MyWebApp")));`

When I tried to use the -o attribute to put the Migrations into MyClassLib project it didn't find them on the database update. I instead created a sub-directory for my context and it is stored in a Migrations folder in the WebApp project.

dotnet ef migrations add Initial -c MyContext -o Migrations/MyClassLib
dotnet ef database update -c MyContext

@hofa77
Copy link

hofa77 commented Jan 28, 2017

@kjbetz Thanks Mannnnn

@ajcvickers ajcvickers reopened this Oct 16, 2022
@ajcvickers ajcvickers closed this as not planned Won't fix, can't repro, duplicate, stale Oct 16, 2022
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

No branches or pull requests

7 participants