I'm using LINQPad with a custom assembly, behind which there is an SQL Server CE database which may or may not exist at the time. The custom assembly uses Entity Framework code-first with automatic migrations, and includes a simple initialiser inheriting from MigrateDatabaseToLatestVersion which will create the database if it doesn't exist. I've been working with it for a couple of weeks and it's been working quite nicely.
This morning, after a small glitch proved frustratingly difficult to diagnose until I realised that a migration had happened between two events in the log, I decided it'd be nice if the database's own log table noted when a migration had been applied. To that end, I added a couple of lines to the Seed() method in the initialiser to instantiate the generic repository/unit-of-work container I've been using, add a record to the logs table, and commit the changes back to the database. The repo has a flag to indicate that it does not own the underlying context, so I can be sure that it doesn't dispose the context I'm then going to try to use.
Now, if I change the model (I'm testing by repeatedly commenting and un-commenting one of the DbSet properties on the context class) then a record is inserted to note that a migration took place. Exactly what I wanted. However, if the .sdf file doesn't exist, LINQPad gives me the following error:
The underlying provider failed on Open
InnerException: The database file cannot be found. Check the path to the database.
While the error message is perfectly self-explanatory (the file can't be found because it isn't there) what isn't clear is why it doesn't just create the file like it did before. What's really odd about this is that if I re-compile the custom assembly and then run the LINQPad query again, then LINQPad will create the .sdf and continue happily. This happens even when the changes to the assembly are irrelevant. In testing, I have run the query, watched it fail, then added a single blank space to the end of a comment in the repository class, re-compiled it, and then run the query again... and it worked. I am completely at a loss to explain how that should have made a difference.
At this point it may be worth mentioning that the "custom assembly" I'm dealing with here is LINQPad's own "My Extensions" file. Yes, I wrote a data context with code-first automatic migrations initialisation and a generic specification-pattern transactional repository in my extensions file. Yes, I realise that's probably not what it's meant for. I was bored, and wanted to test something. Anyways, this may be causing something strange somewhere. It may not, but I thought I'd mention it just in case.
Related
New to EF.
Am using code first but created from an initial database.
First issue is when I added a foreign key to the model After executing add-migrations from the console it created migrations to create the entire tables rather than just adding the foreign keys to the existing tables using AddForeignKey(....),
And when I try to update-database it tries to create a localdb database under and i get the error
Directory lookup for the file "C:\src\Project\App_Data\TheDatabase.mdf" failed with the operating system error 2(The system cannot find the file specified.).
CREATE DATABASE failed. Some file names listed could not be created. Check related errors.
Which kind of makes sense because i'm not using sqlexpress.
It seems as though I need some configuration to coax it into action.
Any useful advice would be welcome.
I found a solution although maybe this is more of a workaround
I did change the connection factory but it did nothing. Still tries to use App_Data folder and looks for an MDF there.
I found a work around though. The package manager lets you override the connection string so i just did that and it works fine.
As for the other part of my question regarding why it was trying to create the tables. What I needed to do first it use the Add-Migration with -IgnoreChanges and update-database will then store an initial blank migration so from then on, any changes you make will be just those incremental ones I was referring to.
Here was the link for that. https://msdn.microsoft.com/en-us/data/dn579398.aspx?f=255&MSPPError=-2147217396
Thanks to those who offered help.
Hope this helps. Basically, EF needs your first snapshot of your database to create the model classes as the initial state, after that you can add migrations.
If it doesn't help, can you post your connection string and number of migrations your have?
When an application is Live an iterative approach to database changes is obviously required. In the db first world I would change the object (eg. column added to table) in the databaae project, then deploy (recreate) to my local instance, then replace the old table with the new in my edmx - when it was go Live time a delta script is generated out of the database project compared to a copy of the Live database schema. Sounds long winded but at the end of the day I only made the change once (the object in the db project) - everything else is generated
Flip over to code first (EF6) and Im expecting a similar one change experience - i.e. I add the property to the class - however do I additionally need to add a migration script ?
I've been reading and it seems many advise to disable migrations to have more control - I'm confused - I had visions of simply deploying the app and the changes automatically reflected in the target database the next time the app runs - one thing is for sure I don't want to manually write separate deployment scripts (or migration code). As mentioned I'm confused about this final part - can anyone clarify - point out the options
Many thanks
Short answer is there's no need to create a 'migration script', you're correct as EF will handle it for you if you want. I think when you read about disabling migrations, you were probably actually reading 'disable automatic migrations'; EF will still generate migrations regardless.
As you pointed out it IS a two-change process when developing: First you change your class, then you open up the Package Manager console and call Add-Migration. Usually, that's all you have to do, and EF will generate the change code for you. Then, you call Update-Database and it does it's work. When you go to deploy, you will connect to your target database and call Update-Database once and it will apply all migrations that are pending.
You can also enable auto-migrations which skips the Add-Migration step, but I always like to review the generated code. Call me old-fashioned ;)
It gets more complicated when you need support for views, SPROCS, and UDFs, but there are ways to do most anything you want to do. And, even though it's a 2 (3?) step process to get changes out to the DB, it's still much easier than changing the DB and code separately, by yourself.
Then, you can follow the steps here to set your deployment up so that once your EF is initialized on a connection to your production DB, it automatically applies the updates. Again, I would advise to do it yourself (via the package manager console) just to be safe but it's not necessary.
I am using Entity Framework 5.0 Data migrations along with code first.
When i add a new field to my model and execute the following command in the package manager console.
"Add-migration AddedField"
All I get is an empty migration called "n_AddedField", the up and down methods contain no logic.
I tried a bunch of things, reinstalling the EF nuget package, cleaning my solution, rebuilding, manually removing all generated files and directories.
Then i decided that i would scrap all my migrations and start over, and then it got weird.
After deleting all my migrations, and the migrationhistory table in the database, i recreated the database using the CreateDatabaseIfNotExists initializer. After doing this, I should be able to create a new initial migration. But when i try to create create a new migration, I get an error saying that there are pending migrations, and lists all the migrations that i just deleted from my project.
I have no idea why and how EF still has any recollection of those migrations.
I even tried searching through filecontents looking if the migrations were saved somewhere else or something. But nothing..
Data migrations look really neat when scott hansleman demo's it on stage, but for real work, I'm starting to look for alternatives.
When the project started, we were using EF 4.x and a while back switcted to 5.0, but since the switch i have added a bunch of migrations successfully.
Does anyone have any idea how to solve this problem?
Basically i just want to be able to add migrations, and generate a sql script with the changes.
I had a similar problem where a new migration was not being found, and so update-database was giving me the following error no matter what I did:
Unable to update database to match the current model because there are pending changes and automatic migration is disabled. Either write the pending model changes to a code-based migration or enable automatic migration. Set DbMigrationsConfiguration.AutomaticMigrationsEnabled to true to enable automatic migration.
You can use the Add-Migration command to write the pending model changes to a code-based migration.
Doing a "batch clean" solved my problem, suggesting EF was using an old/invalid assembly from a folder other than the currently selected 'solution configuration (e.g. DEBUG)'.
Hope this helps someone else out there.
oops. In my case I was adding a new root entity not referenced by any other entity. The result was simply that code first had no reason to generate a migration for the entity. Once I added the code into the DbContext (a dbset) it worked like a charm.
The problem in my case was caused by:
Create a migration (successfully)
Decide that I want to re-create it, and delete the migration .cs file
Try to regenerate it, and end up with empty migration's Down and Up functions
In this case, I forgot to also delete the ApplicationDbContextModelSnapshot.cs entries for the model changes. Removing the new mappings in this file solved my problem and it then generated correctly.
Just got the same problem but figured out that my new field was added as a member variable and not a property - it was missing the {get; set;} part and that makes migration skip that field.
May not be your case but it might help someone else.
You're 'out of sync' - Db, migrations, code - and you can expect all sorts of problems like that.
I did this million times (almost:) and it works really well - but you need to go steady, and be meticulous with what you're doing.
You can read through this 'summary' I made - start half-way somewhere (but also check connection).
Code first create tables
...and if it doesn't work I'd suggest you make a small 'repeatable' scenario / model - post exactly what you have.
How migrations work:
Migrations are tied to the 'migration table'.
When Add-Migration is run - it checks against the 'existing database' structure and migration table - and makes the 'difference' (sometimes you get none 'up' 'down' simply as too are in sync).
So, each 'migration' is a complex diff in between your code, existing migrations, and database, and migration table. Short of removing the database nothing else is certain to reset - Db 'migration' table may not be enough - that doesn't guarantee full 'cleanup' (if possible, I always do full Db delete). You also need to delete your code migrations.
Make sure to 'compile' the projects (best make them compile automatically in configuration) after/before where relevant.
Make sure your 'connection' matches.
Once all is in sync - all should work nicely - but you gotta keep it in sync. Unless you plan to delete the Db (testing) - don't remove migrations just like that (you can use Update-Database -0 (I think) to get back to some migration (this is 'zero state').
I had a problem similar to this, where using the -force flag on add-migration to re-scaffold an existing migration stopped working for no apparent reason.
No matter what I did I got the stupid "Unable to generate an explicit migration because the following explicit migrations are pending" error message. After trying nearly everything I could think of and stopping just short of smashing my laptop to pieces, out of desperation I ran enable-migrations again and of course got the "Migrations have already been enabled in project 'Blah.Blah'" message. Tried add-migration -force again and magically it was working.
I have no idea what it changed- must have been some user settings/config file outside of source control. Hopefully this will help someone else.
The batch build -> clean option did not work for me.
I solved the problem by:
Creating a migration with 'Add-Migration NameOfMigration'
Deleting the contents of the up and down functions of the created migration class.
Updating the database by running the migration script (which will just add a row to the _MigrationHistory table with 'Update-Database -Verbose'
The web application now runs successfully, so essentially I had an issue that was fixed by adding meta-data only.
It happened to me and nothing worked. Then i did this on my own and everything works now.
Problem:
I created a Model "Cars". And When I create a migration for it using command "add-migartion AddCarModel", a migratoin was created but it was empty. I tried with different names and also tried delete migration's .cs file but nothing worked. Then I did the following:
Solution:
Follow below steps:
1. Delete all the empty migrations that you created for the Model. (But remember the names of the migrations for step 2)
2. Also delete those migration entries from "_MigrationHistory" table.
3. Comment out you line(s) of your model DB context, (in my case it is "public DbSet Cars{ get; set; }")
4. Clean and Rebuild solution. (Its best that if you batch clean)
5. Make sure that your update command is working and not throwing errors. (Command: "update-database -verbose")
6. Now uncomment line(s) that you commented in step 3.
7. Now create the migration for that model. (I created the migration with same name as before)
Hopefully it works. :-)
I added a new class to my data model to a sub-directory, the resultant namespace was not visible to scaffolding using add-migration.
Fix was to rename the namespace of the new class to conform to the rest of model, and/or add "public virtual DbSet .." etc into your entity context class, which will require you to reference this new namespace, then run add-migration again.
It seems that i managed to solve the problem by moving the models and the context class to another project.
I still have no idea why this happened, and this solution is really no solution at all :(
I had the same problem. Migrations were enabled but they weren't detecting any changes.
My solution was to re-enable migrations using -Force attribute and then everything worked.
Enable-Migrations -ProjectName -StartupProjectName --ConnectionStringName -Force
I had to delete the _MigrationHistory table that is generated by EF. Then I ran add-migration again. Be careful with this though, as it will generate the queries needed from scratch, including tables that are already there.
In my case it was because I had added a secondary context 'ApplicationDbContext' as part of the ASP.net identity stuff. When I ran the 'enable-migrations' command again I got an error that there was more than one context. Once I combined the two things started working again.
Maybe the stupidest of all:
I was adding a migration with the same name as the new object I was creating.
I had to run dotnet ef migrations remove even though I'd deleted the previous migration
If you are using fluent api to set up your configurations for the DbSets then you won't have any problems with it
I'm not sure what I've done, but I get this error when publishing to azure:
Automatic migration was not applied because it would result in data loss.
Now this is very distubing. My models match my database 100% - so is there a chance there might be data loss if I force it? I'm really confused what to do now.
So much for auto migrations :S Not much automation :)
I think my error was that I created new models, published it and EF created new tables for them. I then remembered that I forgot do add the models to my DbContext. So I added the new DbSets to context and published. That's probably where it went wrong. But then again, I didn't know that EF added models to the database if they aren't POCO classes or what ever they are called. Might have been some foreign keys that triggered.. dunno. Anyways I went undo frenzy on my code and deleted all the newly created tables and stuff to get me to my starting point. I thought that might solve it. But noooee stupid me.
Any ideas where to start on this issue? Im gonna jump off a cliff I lose my data :)
You can have EF create the SQL for you, so you can implement the migration manually. In the package manager console enter:
update-database -v -f -script
It will open a new window with the SQL that you can look over, and then apply yourself directly to the database. The last line that enters an entry into the migration history will allow the DbContext to know it's looking at the correct version.
First make a backup! Especially easy if you're using SQL Compact - just copy the file.
Or with LocalDB or SQL Server, Detach, copy file, Attach..
But to give a little more help, generating that script might still have you look for what might cause data loss. I find that adding a new column to become primary key in a table might loose data even if the original column is kept, because of a NOT NULL constraint being enforced on the new column causing (all) rows to be dropped.
My database model (sometimes referred to as "context") is dynamically assembled at startup based on which services and/or plugins are installed. Plugins and services export their model definition fragments through my IoC container and the application core picks them up and runs them when the DbContext.OnModelCreating method is called.
The question is: Can I (and how do I) use Code First Migrations with this setup?
(below is more information on what I've tried and what particular problems are)
In my previous project, the database was inherited from some old code so we couldn't use any of the Code First database generation stuff anyway. We simply kept a long line of delta scripts and executed them manually on deploy (it was a single-host kind of project).
Now I'm starting a new project, and this time, the database is brand new, ready for Code First to play with. Initially, I was all excited about Code First Migrations, seemed like the way to go. Until I actually tried it. The initial attempt, quite obviously, failed due to the absence of an explicitly defined DbContext in my project.
So far, it looks like the only viable option is to manually code migrations, with which I am perfectly fine. However, it turns out that this is not as simple as just creating a few classes inherited from DbMigration.
After some experimentation on a small test project, I was able to find out that the migration autogenerator adds an implementation of IMigrationMetadata, which, among other things, contains a hash of my model as the values of the Source and Target properties. Presumably, this hash is then used to identify a path across migrations from the "current" state of the database (as recorded in the __MigrationHistory table) to the newest state as defined by the model in code. This totally makes sense, but...
Naturally, I have no idea where to get that hash for my model, which makes me unable to implement IMigrationMetadata on my migrations.
On the other hand, I see that the metadata interface is not included in the DbMigration class itself, which makes me think that it might be optional. It then follows that migrations can actually work without the hash values, but the question is - how?
All the information I could find on the internet is just simple, very basic tutorials. No information on how to create migrations manually (and whether it's even supported). No documentation on how it actually works and how to extend it. And it is not quite obvious from outside.
I am ready to resort to ILSpy at this point, but the whole EF is so complex that I fear I may not be able to find what I need in reasonable time.
Here are a few ideas that you could pull together to find a solution that works for you. I realize I mentioned some of these in our other thread, but I'm including them here for others reading this question.
Automatic migrations allow Code First to automatically calculate and apply changes to the database.
You can write your own code to generate and apply migrations. I've written a post about applying migrations and the MigrationsScaffolder class will help you create migrations.
When you run the project , an extra table is created in the database.
EdmMetadata table
The hash is always created with the help of EdmMetadata Entity and the current code first model. It is SHA-256 hash stored in the EdmMetadata table of the database. You can get it from that table.
Methodology to be followed will be:
Get the hash of the current model using
var hash=GetModelHash(OldContext);
Check whether the model in the code (new model) is compatible with the model in database(old model) using
CompatibleWithModel(hash,CurrentContext,ObjectContext)
This method returns bool.
If it is not compatible, then delete the existing tables in the database.
Create new tables
Save the current hash to the databse
Seed the data.
The code may look like:
{
var objectContext = ((IObjectContextAdapter)context).ObjectContext;
var modelHash = GetModelHash(objectContext);
if (CompatibleWithModel(modelHash, context, objectContext))
return;
DeleteExistingTables(objectContext);
CreateTables(objectContext);
SaveModelHashToDatabase(context, modelHash, objectContext);
SeedData(context);
}
Be sure to make the class inherited from
IDatabaseInitializer<T> where T:DbContext