I have pulled down a Visual Studio 2015 project created my another developer. Within the Migrations folder are several Migration Configuration files ...
201601081315335_AddedPersonEntities.cs
201601091532275_AddedDepartmentEntities.cs
201601101145137_AddedPayrollEntities.cs
I would like to update my database to the point of one of these Migration Configurations. However when I try this command ...
Update-Database -Verbose -StartupProjectName MyApp.Api -ProjectName MyApp.Data -ConfigurationTypeName 201601091532275_AddedDepartmentEntities.cs
I get the following error ...
The migrations configuration type '201601091532275_AddedDepartmentEntities' was not be found in the assembly 'MyApp.Data'.
I was expecting it would bring my database up to the same schema at the point that 201601091532275_AddedDepartmentEntities was created. Am I missing something?
Go to visual studio, select your MyApp.Data and check the "Show All Files".
Inside the migrations folder, see if there aren't migrations "outside" the project. If there is, then add them to the project with Right-Click > Include in project.
Do you use TFS?
It happens when you add something (File/Folder) inside a project in your solution and check-in your solution, and your colleague doesn't do correctly the merge on the .csproj file (Which contains all the information about the files and folders inside the project).
WAIT
Ok i think this isn't the problem.
You are specifying -ConfigurationTypeName: don't you want -target: instead?
-ConfigurationTypeName Is used to define the configuration class (Normally contains the seed method).
-target Specifies to where you want to update your database (From the current migration to that specific one, forward or backwards it works anyway).
And, do you insert the models inside MyApp.Data or MyApp.Models?
Related
I'm having trouble with a migration that seems to have been wrongly deleted by EF core.
It says I have to manually delete some file, since the migration file was not found, but I can't find a guide on how I'm supposed to delete that.
I had my initial create migration
I added a new one for creating a couple more columns in a table
I didn't realize that mi project was set to pgsql instead of sqlite
I deleted the migration (never applied database update)
Ef core delete command deleted the migration files on ./Data/Migrations
I set sqlite
I added a new migration
The new migration was on pgsql again
Delete migration tries to delete the (step 2) migration instead of (step 6) migration and fails.
It says No file named '20220308_Migration2.cs' was found. You must manually remove the migration class 'Migration2', hence the question.
My commands for adding and removing and listing the migrations were the followings:
dotnet ef migrations add name -c MyContext -p .\Project.Db\Project.Db.csproj -o .Project.Db\Data\Migrations -s .\Project.Server\Project.Server.csproj
dotnet ef migrations delete name -c MyContext -p .\Project.Db\Project.Db.csproj -s .\Project.Server\Project.Server.csproj
dotnet ef migrations delete name -c MyContext -p .\Project.Db\Project.Db.csproj -s .\Project.Server\Project.Server.csproj
After all done, if I execute the list command, output shows:
Migration1 (pending)
Migration2 (pending)
Where Migration1 is the initial create and Migration2 is the migration applied on step2.
The files I have on Data/Migrations folder are the ones corresponding to Migration1 and Migration3 (step 6)
Another questions.
Where does the list command data comes from? is there a secret database or a hidden caché folder?
If I just delete the Data/Migrations folder, will I be able to start over with the migrations?
Thanks
My problem was on communication between projects. I failed to mention before that I have my solution splitted between projects (as you can see by the commands), and happens that those projects are linked to each other by hard links (Microsoft's mklink -h) to de .dll of the compiled lower layer project.
What happened was that somehow the hardlink between the DB project and the Server project failed, so the Server project was not aware about the changes on the Db project, and it could only see the DB project as it was at the moments the hard link failed.
I finally deleted the reference and added it again. As soon as I did that, the project recognized the real state of the migrations and everything went smoothly.
So (answering my questions), the message was telling me to delete the migration file in ./Data/Migrations. The file was deleted, but the Server project could not see that.
The "cache" was actually the broken hard-link that referenced an old version of the DB project. The list command scans the folder -/Data/Migrations and compares with the database.
I am kicking the tires with EF 7, specifically the revEng command.
I have been able to run the revEng command and get the context and POCO files generated.
However there are two things I would like to tweak:
The context and POCO files are created in the project root.
The database connection string is hard coded on the context file.
Is there a way to move the file to another folder from the command? In other words, a Models folder? I could move the files manually, but doing that each time I update the model sounds like it would get old.
Is there a way to have the generated context file reference a connection string from the config.json?
If what I ask is not available, is it in the backlog, and this just life in preview land?
The abibilty to specify a project folder will be available in beta 8 https://github.com/aspnet/EntityFramework/commit/5b19fbbff82987ba9e1aafe051ff8c4fd02bf8cf
I excluded some migrations from my project in visual studio and now want to add them back.. I noticed there are 3 files per migration... 2 .cs and 1 .resx...
When I add them all back and compile, then try and run the migrations via Update-Database I get the error:
Could not find any resources appropriate for the specified culture or
the neutral culture. Make sure "..." was correctly embedded or linked
into assembly "..." at compile time, or that all the satellite
assemblies required are loadable and fully signed.
I selected all of the files and then changed the properties to Embedded Resource
Summary:
I'll start with the summary and then follow with the details. For my project, automatic migration is not happening on the live .sdf database file in the working directory. It's as if that .sdf file didn't exist. Instead, all configuration actions are performed on a new, empty database file which it creates on in the Program Files/Microsoft Visual Studio 10.0/Common7/IDE directory. How do I get it to work on my live .sdf database file in the working directory?
Details:
The project uses Code First EF in Visual Studio 2010 Ultimate. The project was started with EF 4.1, and I just updated the project to EF 4.4.
The database file is a SQL Server Compact Edition 4.0 file, which is located in the same directory as the executable (i.e., the working directory). Everything has been working fine for some time now, but I want to add two new DbSets to the DbContext, and hence two new tables to the database file. When I deploy the new version of the program to customers, I want the program to seamlessly just add the two new tables to the database, and continue on as if nothing had happened, leaving untouched all the extant data in the other tables.
Attempt 1
Per the process described in http://msdn.microsoft.com/en-US/data/jj554735:
I added to two new DbSets to the DbContext-derived class. When I attempted to run the program, I got the following exception: The model backing the 'DrillContext' context has changed since the database was created. Consider using Code First Migrations to update the database. This is what I expected to happen, since I hadn't yet enabled migrations.
In the Package Management Console I then issued the command:
Enable-Migrations -EnableAutomaticMigrations.
The system created a Migrations directory with a Configuration.cs file in it.
I then ran the
Update-Database
command, and got the message No pending code-based migrations. I checked the live database file in the working directory, and it was unchanged. There was, however, a new database file with the same name in the Program Files/Microsoft Visual Studio 10.0/Common7/IDE directory that had the same name and was an empty database with all the appropriate tables, including the two tables corresponding to the two new DbSets in the DbContext-derived class, and a new table named _MigrationHistory, which has a single entry in it. The live .sdf file remained untouched, without the new tables, and with no _MigrationHistory table.
Attempt 2, which uses an "InitialMigration":
Per http://www.ladislavmrnka.com/2012/03/ef-4-3-migrations-and-existing-database/
To prepare for the second attempt I restored the program's original state (i.e., to the state it was before I attempted the migrations) by doing 3 things. I removed the 2 new DbSets from the DbContext-derived class. I deleted the Migrations directory (and the enclosed Configuration.cs file), and deleted the useless database file (.sdf file) in the ".../Common7/IDE" directory.
I then executed the command:
Enable-Migrations -EnableAutomaticMigrations
which created the Migrations directory and the Configurations.cs file.
I then executed the
Add-Migration InitialMigration -IgnoreChanges
command, which added an 201208281905525_InitialMigration.cs file to the Migrations directory.
Then, per the directions on the cited web page, I modified the Up method in the file so that the InitialMigration class became the following:
public partial class InitialMigration : DbMigration
{
public override void Up()
{
Sql("DROP TABLE EdmMetadata");
}
public override void Down()
{
}
}
I then executed the
Update-Database
command, and got the message The specified table does not exist. I checked the live database in the working directory, and found that there is indeed an EdmMetadata table in the database. I then checked the .../Common7/IDE directory and found that the new database that had been created there did NOT have the table.
So all "migration" activity is occurring on the .../Common7/IDE version of the file but not on the live database file in the working directory.
How do I get it to work on the existing, live database file?
Thanks,
I'm trying to use EF 4.3 migrations feature. My ASP.NET MVC project stores connection strings in external file:
<connectionStrings configSource="bin\connections.config" />
All runtime procedures (including automatic migrations) work fine. However, no powershell commandlet, connecting to the database, is able to find external file. It throws "Unable to open configSource file" exception. I was trying to place .config file in different places as well as changing configured external file location to no avail. Is there any workaround available?
Update: I've found that EF creates a temporary AppDomain with configuration file located in temp directory. So the only workaround at the moment, it seems, is to place external configuration in the same temp directory. Any other suggestions?
Using EF 6.1 here.
If like me you were linking to a connectionStrings.config file located in another project than your Entity Framework migrations project (using Add as link), you'll probably need to move the file back to this EF project and link to the moved file from the other projects instead...
There are unfortunately no easy way to handle external configSource files with the powershell cmd-lets in EF migrations. I've given up on it and moved the connection strings into the config file for the class library that contains the db code. The alternative is, as you've found out yourself to manually copy the file. Unfortunately the copy process doesn't honor the build settings of the project, so setting the external config file to be copied at build doesn't help.
EF 4.3.1 supports configSource.