I'm building a MVC application with .Net Core and I need to generate the script of a migration.
With EF6 I did run the command
update-database -script
but when I try to do the same with .net Core is throwing the next exception:
Update-Database : A parameter cannot be found that matches parameter
name 'script'
Do you know if there is an equivalent for EF Core?
As per EF documentation you can use :
Script-Migration
If you want to just script all the migrations you can simply call it from Package Manager console like that. If you want to just script the changes from the last migration you can call it like this:
Script-Migration -From <PreviousMigration> -To <LastMigration>
Be sure to check the docs, there're a few more options to the command.
dotnet ef migrations script --help
Usage: dotnet ef migrations script [arguments] [options]
Arguments:
<FROM> The starting migration. Defaults to '0' (the initial database).
<TO> The ending migration. Defaults to the last migration.
Options:
-o|--output <FILE> The file to write the result to.
-i|--idempotent Generate a script that can be used on a database at any migration.
-c|--context <DBCONTEXT> The DbContext to use.
-p|--project <PROJECT> The project to use.
-s|--startup-project <PROJECT> The startup project to use.
--framework <FRAMEWORK> The target framework.
--configuration <CONFIGURATION> The configuration to use.
--runtime <RUNTIME_IDENTIFIER> The runtime to use.
--msbuildprojectextensionspath <PATH> The MSBuild project extensions path. Defaults to "obj".
--no-build Don't build the project. Only use this when the build is up-to-date.
-h|--help Show help information
-v|--verbose Show verbose output.
--no-color Don't colorize output.
--prefix-output Prefix output with level.
so,you can try
dotnet ef migrations script ver1 ver2
dotnet ef migrations script ver1 ver2 -o ./script.sql
This works in .Net Core 2.1
You can use dotnet core cli to generate script
dotnet ef migrations script
Also you can put this to file with new power shell out-file command.
dotnet ef migrations script | out-file ./script.sql
You can also generate a script to rollback a migration by reversing the parameters to Script-Migration. For example, if you have two migrations, BadLatestMigration and GoodPreviousMigration, you can revert to GoodPreviousMigration by using the following command
Script-Migration BadLatestMigration GoodPreviousMigration
Afterwards be sure to Remove-Migration to remove the bad migration
Remove-Migration
This works in .Net Core 2.2.0
This also generates only the SQL
Update-Database -script -TargetMigration TO -SourceMigration FROM
Related
When using Entity Framework Core for a console application i can't scaffold the database.
dotnet ef dbcontext scaffold "Server=;User Id=;Password=;Database="
"Microsoft.EntityFrameworkCore.SqlServer" -c Context -o Models -t Tables -f
Your startup project '' doesn't reference
Microsoft.EntityFrameworkCore.Design. This package is required for
the Entity Framework Core Tools to work.
Ensure your startup project is correct, install the package, and try again.
I've tried to install both Microsoft.EntityFrameworkCore.Design and Microsoft.EntityFrameworkCore.SqlServer.Design. Same problem.
If i set up a new mvc core application i don't get this error. Only when i set up new console applications.
What am i doing wrong?
I ran into a similar problem until I used the Entity Framework Core .NET CLI. Try the following to see if it will work for you:
dotnet new console
dotnet add package Microsoft.EntityFrameworkCore.SqlServer
dotnet add package Microsoft.EntityFrameworkCore.Design
dotnet ef -h
You should see the EFC CLI Options screen. Do the following to scaffold (replace connection string with your own):
dotnet ef dbcontext scaffold "Server=.\;Database=AdventureWorksLT2012;Trusted_Connection=True;" Microsoft.EntityFrameworkCore.SqlServer -o Model
Once you to that, you should see a Model folder in your project with the class files representing the entities.
I work with .NET Core SDK version 2.1.302. My solution has two type of projects: libraries and web. All libraries are targeted to .NET Standard 2.0: <TargetFramework>netstandard2.0</TargetFramework> and web projects have multiple targets: <TargetFrameworks>net462;netcoreapp2.0</TargetFrameworks>
I have two CI builds: for Windows which uses net462 and build in docker based on linux with netcoreapp2.0.
In the docker build to build my solution I use the following line of code:
RUN dotnet build ./MySolution.sln --configuration Release --framework netcoreapp2.0
And build fails with the rrors like this:
Assets file '/app/MyLibraryProject/obj/project.assets.json' doesn't have a target for '.NETCoreApp,Version=v2.0'. Ensure that restore has run and that you have included 'netcoreapp2.0' in the TargetFrameworks for your project. [/app/MyLibraryProject.csproj]
It happens because as I mentioned before my library projects are targeted only one framework - netstandard2.0
So, my question is how to deal with this situation? How should I specify that projects with only one target framework should ignore --framework param?
In the interests of making sure the answer is noticed, I found that the best way around this was #José Pedro's solution from the above comment stream.
In the csproj file, I put a condition on the TargetFramework element. Now it looks as follows:
<TargetFrameworks Condition="'$(CoreOnly)' != 'True'">net472;netcoreapp2.1</TargetFrameworks>
<TargetFramework Condition="'$(CoreOnly)' == 'True'">netcoreapp2.1</TargetFramework>
It will then by default compile both, but you can pass a CoreOnly parameter to only compile the .NET Core framework.
dotnet build MySolution.sln /p:CoreOnly=True
Another possible solution is to check which framework is available and set the <TargetFramework> dynamically in the build time:
<FrameworkDescription>$([System.Runtime.InteropServices.RuntimeInformation]::FrameworkDescription)</FrameworkDescription>
<TargetFramework Condition="$(FrameworkDescription.Contains('NET 5'))">net5</TargetFramework>
<TargetFramework Condition="$(FrameworkDescription.Contains('NET 7'))">net7</TargetFramework>
It will make dotnet build just work without any additional parameters on a system where only net5 or only net7 is installed.
If I want to specify a logger where I can set the name and location of the log file, I do the following:
dotnet build /l:FileLogger,Microsoft.Build.Engine;logfile=MyLog.log
This syntax has worjked for me in the past with msbuild, however it is not working with dotnet. What am I doing wrong?
I took me some time to find this, but you can use fileloggerparameters (flp)
dotnet build /flp:v=diag
This will create log file msbuild.log. The Option [v]erbosity is set to [diag]nostic. But you can choose others verbosity levels.
Use the option logfile to specify the name of the log file.
dotnet build /flp:v=diag;logfile=MyLog.log
This also works with msbuild
msbuild /flp:v=diag;logfile=MyLog.log
Using Powershell the command for dotnet looks like
dotnet build /flp:v=diag /flp:logfile=MyLog.log
Does anyone know how to change the output directory of the following command?
dotnet ef migrations add Initial --context EsportshubApi.Models.ApplicationDbContext
I tried to add the option:
--content-root-path 'Migrations/Identity'
But that doesn't do anything. There is a --data-dir option as well and something else with directory. But none of them is the output for migrations.
My problem is that I have 2 DbContexts so I want their migrations to be separated.
dotnet ef migrations add Initial --context EsportshubApi.Models.ApplicationDbContext -o YourFolderPath
dotnet ef migrations add
Adds a new migration.
Arguments:
Argument
Description
<NAME>
The name of the migration.
Options:
Option
Short
Description
--output-dir <PATH>
-o
The directory used to output the files. Paths are relative to the target project directory. Defaults to "Migrations".
--namespace <NAMESPACE>
-n
The namespace to use for the generated classes. Defaults to generated from the output directory. Added in EF Core 5.0.
Also here are the common options you can use with this command.
Source
For Package Manager Console run this command:
PM> Add-Migration 001 -OutputDir "Data/Migrations"
My structure is:
.AspCoreProject
-Data
-Migrations
20190721162938_001.cs
MainDbContextModelSnapshot.cs
Update:
For removing last migration use:
PM> Remove-Migration
Note: If the migration is already applied to the database, then you will get this error:
The migration '20190721162938_001' has already been applied to the database. Revert it and try again. If the migration has been applied to other databases, consider reverting its changes using a new migration.
Then run:
PM> Remove-Migration -Force
If your migration is not the last migration. first, rollback to the migration you need by Update-Database then delete all migration classes after that migration.
PM> Update-Database -Migration 001
This will revert all migrations after 001
In EF Core 5.0, you are free to move Migration files and changes their namespace manually. New migrations are created as siblings of the last migration. Alternatively, you can specify the directory at generation time as follows:
.Net core CLI
dotnet ef migrations add InitialCreate --output-dir Your/Directory
Package Manager Console
Add-Migration InitialCreate -OutputDir Your\Directory
EF Core 5.0 documentation
You just need to use -o Or --output option with your command,
To do so, you need to explore to your root project folder, eg: C:\project\SampleAPi\
and use this command
dotnet ef migrations add DbInitial --context SampleAPi.Infrastructure.DbContext -o Infrastructure/Migrations
and then
dotnet ef database update
Before I can use msbuild command in command line and pass the profile as a parameter. Is this currently supported in dotnet cli or is there a new way to build projects/solutions in .net core projects?
Under the hood, the dotnet cli is now mostly using msbuild to do the actual work (excluding dotnet new and dotnet run). So if you're doing a dotnet build, it's actually using msbuild internally.
You can still use msbuild parameters when using the dotnet cli, you need to use the following:
dotnet msbuild <options>
One option is /property:n=v which passes in your property name/value pairs directly to msbuild as you used to do with msbuild itself. You can also continue to use semi-colons between pairs, e.g.:
dotnet msbuild /property:WarningLevel=4;Configuration=Release