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).
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 am setting up an Azure Release Pipeline and I need to execute any pending DB Migrations as part of the release.
I have been scouring the internet for over an hour and everything I can find is about dotnet Core, while the database is EF6 on .Net Framework, not dotnet Core (I've done this several times before for Core).
The problem, as I see it, is that EF6 works using Visual Studio's built in Package Manager Console - This just doesn't exist in an Azure Pipeline; It's a Visual Studio weirdness.
There seems to be several ways I can skin this cat, in my head, but I can't figure out how to start with either of them within the context of the pipeline...
OPTION 1: Run the Migrations on the Pipeline - but... how?
OPTION 2: SQL Scripts - Requires running the Package Manager to generate them so they can be run (if I could do that on the pipeline then I'd just run it anyway so these would have to be created locally and committed with the code which is somewhat backward as a solution IMO)
OPTION 3: Write a console app - Do I really have to do this??
You can try Entity Framework Migration Extensions.
This task allows a Build / Release to provide database connection parameters and execute an Entity Framework 6 migration against the database.
Build your project to an output folder and include the migrate.exe executable that comes with Entity Framework 6.
Create an automated build that packages up your files and makes them accessible during a Release.
Create a Release definition for the relevant Build
Add an EF6 Migration task. Once that task is added to an environment within the release, you'll need to enter the appropriate parameters to configure it. All file path parameters should be within the file system for the build, none of them are for TFS source control paths.
You can also check this article.
The answer here is to use the ef6.exe command line tool and make sure it gets shipped with your build.
This could be useful to anyone here until Microsoft update the non-existent docs: http://github.com/dotnet/EntityFramework.Docs/issues/1740 - This contains a table with a kind of translation matrix between the two.
Is there an easy way to scaffold migrations using old EF outside of Visual Studio? I would like to do it via Rider IDE if it possible.
I don't see these options related to ef core. The plugin makes sense.
(For MacOS, be sure, your dotnet root folder path is /usr/local/share/dotnet/. I'm telling this because Rider installs and places it in another folder. Further it gives rise ef to not work properly. You can see your dotnet folder on terminal by writing which dotnet)
Installing that plugin,
Then,
You can also use a jetbrains plugin made for handling migrations
https://plugins.jetbrains.com/plugin/17026
For EF Core, you can use https://blog.jetbrains.com/dotnet/2017/08/09/running-entity-framework-core-commands-rider/
For EF 6 you may want to check https://blog.jetbrains.com/dotnet/2018/04/06/entity-framework-support-rider-2018-1/
The Package Manager Console tools such as Add-Migration, Scaffold-DbContext commands are PowerShell-based, and the Package Manager Console ties to several Visual Studio-specific objects making it impossible to host it elsewhere - in your case Rider.
In Rider's terminal or anywhere outside of Visual Studio, you can use CLI tools. Equivalents to the highlighted commands would be respectively:
Add-Migration => dotnet ef migrations add MigrationName
Scaffold-DbContext => dotnet ef dbcontext scaffold
You can get more details on JetBrains blog: Running EF Core commands in Rider
I modified a property in the model and it turned out it is not supported by the version of SQLite. This is the error. {"SQLite does not support this migration operation ('DropColumnOperation'). For more information, see http://go.microsoft.com/fwlink/?LinkId=723262."}
So I decided to roll it back by using the command Update-Database Migration "MyFirstMigration" but an error shows up on the console which states Update-Database shouldn't be used with Universal Windows Platform apps. Instead, call DbContext.Database.Migrate() at runtime.. This code recommended is already the code executed at the first run of the application that generates the first error above.
I am really going into circle here. Can someone suggest how I can rollback/downgrade MySecondMigration ti MyFirstMigration?
Can someone suggest how I can rollback/downgrade MySecondMigration ti MyFirstMigration?
For the same DbContext, just execute Remove-Migration command on your package manager console, it will remove the last migration of this DbContext. It is your MySecondMigration which will be removed and only MyFirstMigration left.
Update-Database shouldn't be used with Universal Windows Platform apps. Instead, call DbContext.Database.Migrate() at runtime
For this, just as this error shown, DbContext.Database.Migrate() applies any pending migrations for the context to the database, include what Update-Database did (Updates the database to a specified migration). By testing on my side, for the same DbContext, every new migration is the updating based on the old one. DbContext.Database.Migrate() will apply all the migrations for updating. If you don't want the latest update, just remove it for roll back.
In a standalone entity framework 7 project (note, not a MVC project with an entity context where the command DNX might be used), how can I run a migration on a remote database using Powershell?
I am currently using Entity Framework 7.0.0-rc1-final with Visual Studio 2015 (14.0.23107.0).
At the moment there is no way you can use pure PowerShell to do this because a utility like migrate.exe does not exist yet and importing the EF PS modules is not possible as they require a Package Manager PowerShell Host.
Here are some ideas how you can update a remote db in EF7:
One thing you could do is use the package manager console commands from within VS as usual to update the remote db. You can create a second context that has the remote db connection string and use the update-database command specifying the context to use. These commands require the following package in EF7:
https://www.nuget.org/packages/EntityFramework.Commands/.
I have done this successfully in a class lib project.
Another solution would be to use DNX commands by creating a DNX project instead of a classic one. DNX projects are not just for web sites, it is just another type of project. Here is a link that shows how to create a console app DNX project:
http://docs.asp.net/en/latest/dnx/console.html.
So with this type of project you can use the provided DNX commands that you seem to be aware of.
I hope this helped. Maybe we can give more help if you describe your situation and your end goal in more detail.
Answer too long as a comment, so adding it here...
Have you looked at this article and the links in the answer?
From that answer
The problem with importing the module into a PowerShell console is that I believe the module expects to run in a context where it has a Visual Studio DTE object available. That environment is the NuGet Package Manager Console. This issue has been brought up before. Check out this blog post and this SO question.
This blog post shows how to write code that does migrations.
What might be helpful for readers of this question is what you have tried, what is not working, and other information that might help solve your problem.