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!
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!
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
Thanks @joeaudette. Basically you created another Web App with just the information the migrations tool uses.
Very dirty!! Hope they fix this soon.
@joeaudette how will the migrations be performed in production? Does the WebApp know which code to run to apply the latest migrations?
@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
This is probably a duplicate of this issue: https://github.com/aspnet/EntityFramework/issues/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
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.
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
@kjbetz Thanks Mannnnn
Most helpful comment
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 MyClassLibProjectdnx ef database update -c MyContext -p MyClassLibProjectWhen I tried to do this in RC2 I got the above errors. but it suggested:
So, I simply did what it said.
When I tried to use the
-oattribute 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/MyClassLibdotnet ef database update -c MyContext