I'll preface this with I'm fairly new to EF and I had to mess around with this quite a bit to get the initial deploy to work, so I may (probably) have inadvertently broken something.
My problem is now when I create a new migration it builds fine, but when I try and update the database, it errors because it's trying to recreate tables that are already there.
If I remove the migration, I can update fine.
I tried making a migration before I make a change and then again after, but same thing.
Doing a compare with unmodified on the snapshot seems to be just updating with my new table.
__EFMigrationsHistory just has my first release migration.
When I was messing around to get the first deploy I did remove a load of old migrations, is there somewhere else these could be logged that's throwing this off? Although I don't think I removed anything after the migration I kept.
One other thing I did do was update EF from 6.0.6 -> 6.0.8
Any help to get this back on track would be much appreciated.
Related
I'm pretty unsure what's happening here. Any time I run Update-Database I get the successful Running Seed method. when I'm finished. However, when I go to the __MigrationHistory (or look for the added columns), nothing changed. This happens when I use -TargetMigration as well. No matter what I do, the database isn't getting modified.
I'm not even sure what other info I can include to help narrow down the solution. Any tips?
Edit - Forgot to mention that I've run with the -Verbose flag and the connection is the same one I am currently using in Server Explorer.
I don't want to sound like a jerk here, but it feels like the desktop and mobile applications have been forgotten when migrations were documented.
Given:
It is unacceptable to ask an end user to run any commands to create or migrate a database.
Its not an Asp.Net Core web application so I don't have a startup.cs scaffolded.
When the software is updated on an user's device it must update its own database without user intervention the next time it runs.
This is a code first project.
I'm pretty sure its just a matter of getting the IOC container that the entity framework core code will use and putting the right things into it, but I'll be damned if I can figure out how. Despite my best google-jitsu and bing-fu, I've only been able to find docs or examples that show running using startup.cs in web projects or using the Entity Framework core CLI tools.
public void SomeDesktopAppStartupMethod()
{
var context = new DesktopAppContext();
// ??? - register some migration locator with the IOC container? ¯\(°_o)/¯
context.Database.Migrate();
// Profit!
}
Right cause there really isn't much to the migrations of your database within in a mobile. Since more than likely you are using SQLite (guessing) mobile/uwp apps don't get some of the same treatment that Web gets this is a function of MS not pushing mobile at present if you hadn't noticed. Unfortunate for most of us early adopters but early bird doesn't always get the worm.
More than likely those doing Desktop are going to be using EF not EFC and not usually target SQLite but SqlExpress or SqlLocalDb
Most of my changes for my apps are surface level changes to the database but due to limitations of the migration system you would have to write your own SQL into the UP/Down of a migration to drop columns in SQLite and the reverse to undo your changes. The is a SQLite only limitation at present, for EFC provider.
As for location in the application where I process any migrations since I am using template10 (which is in a refactoring at present) is done where the UIElement CreateRootElement(IActivatedEventArgs e) is being created. Another location to consider would be OnStartUp for the app. It would vary based the development you are doing of course XPlat might make sense where all flavors could take advantage.
Some apps when syncing data I don't bother with migrations and wipe and recreate cause its just easier from that standpoint since all data is server based on Azure.
That being said there are major changes coming from 2.0 with respect to SQLite and EFC, if read correctly there will be a heck of a lot more control over how things are "migrated" or modified from Version X.X of your app.
We're using EFCore and SQLite for our Desktop app! This is what we did for the InitialCreate migration, I can't speak to subsequent migrations, but they should be similar (solution left as exercise to the reader):
1.For the project that contains the DBContext implementation, change the csproj ItemGroup section to include
2.Right click on the project and select Open folder in File Explorer
3.Enter cmd in the command window
4.In the command window enter: dotnet ef migrations add "xxx"
where "xxx" is the name of your migration e.g. InitialCreate, or AddNewTable
5.This resulted in some error messages for me, but in the end it created a
migrations folder with 3 new classes. Date_xxx.cs Date_xxx.Designer.cs and a YourDBContextClassModelSnapshot.cs. Add the folder and classes to your project/source.
6.Ensure your DBContext implementation has an empty ctor.
7.Replace your call to context.DataBase.EnsureCreated() with
context.DataBase.Migrate()
8.Rebuild, sacrifice a few chickens, cross your fingers and hopefully the Migrate() now creates a db with version/migration info. You can edit the .DB file which is mostly binary but will have some text like the following, which does not exist when created via .EnsureCreate()
"MigrationId" TEXT NOT NULL CONSTRAINT "PK___EFMigrationsHistory" PRIMARY KEY,
"ProductVersion" TEXT NOT NULL
Notes: the first time I ran the dotnet command it failed because the EFCore designer/tools weren't loaded. I did some project rebuilds and it seemed to work after that. Also i had a lot of problems with the app during runtime getting "EFCore assembly failing to load" crashes due to different projects referencing different versions. Took many clean/rebuilds to get this working again once the .csprojs were tweaked to ref the same version. Also, out of curiosity i tried The "ef migrations remove" command, but it failed to execute (unable to load Sqlite3), fortunately we don't need to use that cmd yet.
I just got back to an old project that uses Entity Framework and when I run it I get the dreaded "The model backing the ‘MyContext’ context has changed since the database was created. Consider using Code First Migrations to update the database ..." error. The problem is that nothing should have changed. Is there any way I can proceed to analyze this issue and figure out what changes is causing it?
I have examined the InvalidOperationException I get but I have been unable to find any clues anywhere within.
I would really appreciate some good advice on this one.
Thanks.
I often get errors when running test cases after changing relationships. When checking the relationships on the data diagram I notice that they are often not reflecting any of the changes I did or only some of them, confusing the model. This only seems to be the case when creating the diagram within Server Explorer of Visual Studio. When creating the diagram in SQL Server the changes show up fine.
Unfortunately, this also affects testing the code, because I'm never sure if a fails because of a problem with a change in the relationships I did or Visual Studio not updating. Having to detach and attach the database each time is a bit of a pain.
The database is dropped and recreated correctly, but Visual Studio seems to run the code against a cached version. Had anybody else similar problems, any fix?
I've certainly seen issues where I've updated SPs/function imports and tried to update the associated complex type, the dialog window says 'update', 'delete' etc next to the columns changed, so it's certainly seeing the different, but when applying the update these often don't seem to take and I end up manually adjusting the complex type.
In the above example I'm not sure whether the correct approach is to delete and recreate the type, but the existence of the update functions seem to suggest that an update should be possible. As you say mine too feels like a caching issue and whilst I've not yet found a solution I will be interested to see if you can find a solution, if I make any ground on this I will post back here too!
I am using core data for my app and I never had any problems adding or removing columns until recently. But now even if I make changes to my xcdatamodel and generate new and updated entity h/m files, sqlite doesn't seem to be picking up the changes. I actually went over to the documents folder and inspected the create statement for the relevant tables in sqlite3 and I was able to confirm that the columns I added were missing.
I removed and redeployed the app several times to no avail. Is it possible to do something to the app to make it disregard any schema changes being made through xcdatamodel? I guess another thing I should mention is I recently started putting my entire projects folder in CVS so I wonder if something got messed up in the checkin and check out process.
Sorry. I feel like an idiot. A combination of "Reset Content and Settings" on the Simulator and a "Clean All Targets" in xcode seems to have fixed it.