I have been using F# for some time, and really liking it.
I want to use type providers for data access, but would love to have entity framework migrations.
Can I use EF migrations without entity framework? I am fine with writing migration code by hand, hopefully in F#.
In the case where you want to use EFCore, it's possible to isolate only the migrations in a C# project with MigrationsAssembly.
For example in a DbContext module:
let setupOptions (optionsBuilder: DbContextOptionsBuilder) =
optionsBuilder.UseNpgsql(
"Host=localhost;Database=mydb;Username=postgres;Password=postgres",
fun opt -> opt.MigrationsAssembly "MyProject.Data.Migrations" |> ignore)
|> ignore
Services configuration:
services.AddDbContext<DbContext.MyDbName>(DbContext.setupOptions)
CLI:
dotnet ef migrations add CreateFoo -p ./MyProject.Data.Migrations -s ./MyProject.Api -v
dotnet ef database update -p ./MyProject.Data.Migrations -s ./MyProject.Api -v
There is also a work in progress project to support F# design-time:
https://github.com/bricelam/EFCore.FSharp
F# type providers imply that there is already external data source i.e. they are inherently "Db First". Using EF Code First only to automatically generate migrations is not the best idea, I recommend plain SQL and some tools to keep track of migrations such as dbup.
I answered it in details in similar but bigger question.
You can certainly use EF migrations without using EF in your app. Create a separate project and use Code First migrations.
I'm not aware that the migrations scaffolding feature supports F#. Either suffer with C# for migrations or translate the code yourself?
Related
I am in the process of migrating from EF6 and .Net Framework to EF Core and .Net.
Previously I had a solution for the data model (Data project below) that built and deployed to a nuget package
Solution
Data
SchemaX
...
SchemaY
...
...
Data.Migrations.SqlServer
Migrations
SchemaX
20220701110223_Migration1.cs
...
The data model can then be consumed by any number of separate jobs/apps/etc using the package. This worked fine using EF6. However, if I start again for EF Core I'm seeing the odd issue.
Using the package manager console with default project Data, I can type
add-migration -StartupProject "Data.Migrations.SqlServer" -Context "Data.SchemaXContext" -OutputDir "Migrations\\SchemaX" -Name:CoreInitial
and it will scaffold a migration. The migration ends up in the Data project due to this default. If I use the Data.Migrations.SqlServer as the target/default it cannot find the context - I assume there is something that I could put in this project (other than a reference) to point it in the right direction?
I'm basically trying to migrate frameworks and use the suggestion here to set a start point for core.
NB The Data.Migrations... project is used as the startup as the Data project is .Net Standard 2.0 targetted to allow for use in framework and .Net projects whereas the migrations project has been set to target Framework 4.8.
Edit
Removed the following as it has been fixed by use of the modelBuilder.Ignore<> directive to handle where contexts crossover.
However, what it scaffolds is not limited to the context provided - it basically scaffolds the entire database, all schemas/context items - and using this mechanism as it stands I cannot get it to reference a database for comparison like I could EF6 with it's connection string parameter. I'm not sure whether the scaffolding of the entire model is a configuration issue or the lack of start point database.
I have an ASP.NET Core project with a data access layer using EF Core 3.1.8 and also using version 3.1.8 of the cli tools. The presentation layer and the data access layer are in different projects. To run EF commands in the cli, I open a developer command prompt, navigate to the directory containing the data access layer and run a command such as
dotnet ef migrations add MyMigrationName --startup-project ../Site/Site.csproj
or
dotnet ef database update --startup-project ../Site/Site.csproj
Site is just a placeholder here. The actual project name is longer and it is inconvenient to provide the --startup-project argument each time I want to run a command. Is there somewhere I can configure that so that I can run commands more concisely like dotnet ef database update?
Create a file named ef.cmd in the data access layer directory with the following contents:
#dotnet ef --startup-project ..\Site %*
Then you can use:
ef migrations add MyMigrationName
or
ef database update
For completeness, another option is to use response files. This isn't as simple, but can be useful when you have multiple sets of options. (e.g. for multiple DbContexts)
Create a file named something like identity.rsp with the following contents.
--startup-project=..\Site
--context=IdentityContext
And use it like this.
dotnet ef database update #identity.rsp
I know this is that type of question that was asked before but I couldn't find a valid answer to it.
So, is there a possibility to change where migrations are stored? I'm using EF Core.
FYI: I know that if you move the first generated migration, the upcoming ones will be placed in the same location.
For core EF projects, you can specify the output directory with the '-o' or '--output-dir' option after Add-Migration.
Example:
Add-Migration -o Data\Migrations
If using the dotnet core CLI command, you can specify the same option:
dotnet ef migrations add -o Data\Migrations
Sources and more info:
https://docs.efproject.net/en/latest/miscellaneous/cli/powershell.html
https://docs.efproject.net/en/latest/miscellaneous/cli/dotnet.html
How to run those dotnet.exe ef <command> commands programmatically in .NET Core?
For example to add migration I'm running in terminal dotnet ef migrations add NewMigration and it will indeed create Migrations folder with migration classes, but to create new Migration (for example) programmatically from C# code?
Don't suggest Process.Start("cmd bla-bla") since code should be cross-platform and that dotnet ef runs some code from some EntityFrameworkCore package anyway. Question is what code?
EF Core API isn't really designed for the scenario, but if you want to do this anyways, you'll need to repeat the logic that "dotnet-ef.dll" does to gather project context and compilation output, and then instantiate and use MigrationsOperations manually.
See https://github.com/aspnet/EntityFramework/blob/1.0.0/src/Microsoft.EntityFrameworkCore.Design.Core/Design/MigrationsOperations.cs and https://github.com/aspnet/EntityFramework/blob/1.0.0/src/Microsoft.EntityFrameworkCore.Design/Internal/OperationExecutor.cs
Use caution: these are "Internal" APIs, which means their usage may break from version to version. "dotnet ef" is going to change a great deal between the current release (1.0.0-preview2) and the next release. (For example, the entire tooling implementation will change. See https://github.com/aspnet/EntityFramework/issues/5334).
I use Entity Framework 7.0.0-beta7. If I want to update my database with 'dnx ef update database' I get a 'done'. But nothing happend.
Is there a way to manually (in code) start the migration and debug it?
Update: no it works
I moved the mode back to the web project,
called 'dnvm install latest'
called 'dnx ef database update -c myContext' because I have more
I meet a same issue in EF RC1. and i have a finding, hope it can help you.
i create a project to involve entity model and EF DBContext. then web project reference the project.
run these commands, not working:
dnx ef migrations add MyFirstMigration
dnx ef database update
results
but when i move the DBContext class to my web project, models still in other project, it working fine.New result
so in my scenario need make sure DBContext in Web project.
****Database Migration in Entity Framework 7 Asp.net 5 Mvc 6****
run cmd
C:>Path of Project>dnvm install -1.0.0-rc1-final
C:>Path of Project>dnvm use -1.0.0-rc1-final
C:>Path of Project>dnx ef migrations add InitialMigration
C:>path of Project>dnx ef database update
if you use multiple DbContext then we need to specify Dbcontext
C:>Path of Project>dnvm install -1.0.0-rc1-final
C:>Path of Project>dnvm use -1.0.0-rc1-final
C:>Path of Project>dnx ef migrations add InitialMigration -c DataContext
C:>path of Project>dnx ef database update -c DataContext
If your project is A and you put your DbContext in a separate class library say B, you need to append .MigrationsAssembly("A") after UseSqlServer(...) in the Startup.cs, please refer to https://github.com/aspnet/EntityFramework/issues/3840