We have a Web Forms app using VB.NET. When we first started the project a couple years ago, we though DB Migrations was a great idea! However, the actual use of it was not as grand. So we tried to disable it. We followed the steps as outlined in the dozen or so articles including:
Remove the Migrations folder
Remove the __MigrationHistory table
added Database.SetInitializer(Of MyContext)(Nothing) to the constructor of MyContext
I have not found any form of "Disable-Migrations", only re-enabling migrations with more parameters which makes new config files and reinitializes migrations.
Even with all of this, EF keeps querying the database for the __MigrationHistory table which it can't find, so throws an error Invalid object name 'dbo.__MigrationHistory'.
How can we completely remove Migration History so EF stops using it?
Related
How to properly work with migrations during development when the model is not in its final form or there are still some inconsistencies in relations?
Should migrations be treated more as commits in version control system like git and represent even the smallest change, or what?
Should I add new migration for each small change in my model, or should I just re-create the database and initial migration until I'm satisfied with how my model looks? I can still remove all those migrations in the end and create initial one to clean those small migrations up.
How to properly name migrations? Most often I can't come up with a good name and I give them some meaningless names like X1, X2, X3
Similar questions:
How to deal with database changes during development with EF Core?
1: I personally would keep it as a history. Of course you could always delete all migrations and create one that contains everything but imagine that migration after you have added 100++ tables (entity-types) and you cannot make sure your production database for instance is being updated, when you only have one migration with same name that you just always recreate.
2: Yes, you should indeed make small migrations. You can undo a migration by updating your database to a specific migration and then removing all the others before step by step. This at least works with the package-manager-console tool (maybe also with dotnet tool).
For instance you have already added a migration with models that have changed you go back to the old migration by using this command:
Update-Database -Migration MyMigrationBeforeBadModelMigration
Be aware that this might drop tables if some were added in the migration that you want to undo.
Then remove bad migrations step by step
Remove-Migration // will always remove the latest migration so repeat that if you have many to remove
Then just create the new and proper migration and update your db.
3: Yes, give them proper names. For instance CustomerEntityAdded or CustomerUniqueNameIndexAdded.
Can anyone help me please? Right now i'm connecting my web API project to an existing database. Someone suggested to use EntityFramework for that. I'm applying code first approach in the "Entity Data Model Wizard", but the problem is i'm actually supposed to just import tables, but in the "Choose your database Objects and Settings" part, i accidentally imported views as well. so i was thinking to undo the import.
I read that after the Code First wizard, an app.config file should be added to the project, but this file is missing. The .edmx file is also not found. I've searched all files in folders but still not found. But when i looked at the ConnectionString tag in the web.config file, the new connection that i created in the wizard is there.
Please follow below steps to update the EDMX from database again:
Open the EDMX file
2. Right Click on the EDMX file and choose the "Update Model from Database"
3. In the new wizard go to the "Delete" tab and expand the Views
4. Check the Views you want to undo
5. Click on "Finish"
Hope this helps you.
First, a couple of remarks:
I'm applying code first approach in the "Entity Data Model Wizard"
Code First means that there is no .edmx file. There are migration files and code mappings.
I read that after the Code First wizard, an app.config file should be
added to the project, but this file is missing
Not 100% sure here, but I guess that if your project already has a web.config file it will be used instead of adding a new app.config file (they are basically the same).
So, the thing is that you have to enable and use code migrations, you have to generate POCO classes for your entities (if you don't have them already), and you have to add a database context that extends DbContext and includes DbSets for your entities, and some database initialization code.
This page explains how to do the most difficult part of all of that: dealing with the code migrations. Although it assumes that you are migrating from an existing edmx model and using Power Tools you can just ignore that part and focus on the useful information about the migrations. That is, skip directly to Step 2 in the page.
About removing the views you imported, I guess you didn't get to the part where you generate the migrations, so probably you just have to delete the POCO classes created for the views, and possibly also remove the DbSets added to your DbContext for those entities.
If you generated some migration you can either generate a new migration or modify the existing one. This can be done by adding explicit Ignore mappings for your view entities and running Add-Migration again. If you didn't get to the migrations part yet just ignore this last paragraph.
Hope it helps.
I'm trying to understand the different types of migration paths we can choose when developing an ASP.NET Core 1.0 application with EF Core. When I created my first Core application I noticed it generated a ApplicationDbContextModelSnapshot class that uses a ModelBuilder to build the model.
Then I read that if I need to add a table to the database, I need to create the new model and run the command line to generate the migration file and update the database. Ok, I get it up to this point.
But when I do that, I notice that the ApplicationDbContextModelSnapshot class gets updated too.
1) Does that mean I cannot modify this ApplicationDbContextModelSnapshot class since it looks like it gets regenerated each time?
2) Should I use Data Annotations to build my model or should I use Fluent API which tells me to build my model in the ApplicationDbContext class? Huh? another file that builds the model?
I'm seeing three different ways of working with the database here, the snapshot class, data annotations, and fluent API. I'm confused because today, I made a mistake in my last migration file so I deleted the file, dropped the database and reran the database update.
But by doing that I got errors similar to:
The index 'IX_Transaction_GiftCardId' is dependent on column 'GiftCardId'.
ALTER TABLE ALTER COLUMN GiftCardId failed because one or more objects access this column.
So naturally I was wondering if I had to modify the ApplicationDbContextModelSnapshot class.
What is the path I should be taking when it comes to migrations or database updates because these three paths are confusing me.
I have run into this issue before when I create migrations, make model changes, create new migrations, and try to update the database. The root cause is when keys are being changed and relationships are not dropped and are not added back or do not exist.
You have two options
Easy Method
The easiest way is also the most destructive way and only possible in a dev environment.
Delete all migrations, drop the database, create new migrations and run 'update-database'.
Hard/Safest Method
This is the most time consuming method. I recommend do this in a local integration branch first, pushing it to a remote integration, and then production.
Open the migration file, ie 20160914173357_MyNewMigration.cs.
Drop all indexes in order
Drop/Add/Edit table schemas
Add all indexes back.
For either method, just be sure to test and test again.
Do not modify ApplicationDbContextModelSnapshot. It is a design-time artifact, and should only be modified in the case of a merge conflict.
To update the model, always use data annotations or the fluent API.
For more information on the EF Migrations workflow, see Code First Migrations. It's for EF6, but most of the information is still relevant.
i was working on an application and drop/creating the database on each launch. Now, before going into production, i enabled migrations. I created an initial migration, then changed one of my models, added a new migration, updated the database, and everything was dandy
now, I tried to change the database name in the context, to see how it would behave on a new database, and every time I launch the application I get a differed exception.
right now its "invalid object name".. on one of my tables i think. I'm looking at answers here and they say to refresh the intellisense cache but I can't find where. I went to edit -> intellisense -> theres no refresh cache, theres refresh remote resources, which didn't fix anything.
by the way, do I have to turn automatic migrations on? (i.e. 'true')
When I debug the following code, I receive the message "System.TypeLoadException was caught" when I perform the Delete().
Using db As New ScholarshipEntities
db.ApplicationHistories.Where(Function(h) h.HistoryTypeId = 0).Delete()
db.SaveChanges()
End Using
I am using EF 6.1 in Visual Studio 2013. I also have the EntityFramework.Extended library installed.
I have no trouble querying results. I thought the bug might occur when the Where method has no results, but that is not the case. I also have no problem adding new models (.edmx), which was a problem some people with this exception had.
I just recently upgraded to EF 6.1 and installed the Extended library. This is my first time using one of the extended methods. I've un-installed and re-installed the nuget packages with no success.
IntelliTrace shows the following exceptions from the Delete() call (in order):
'EntityFramework.Reflection.DynamicProxy' does not contain a definition for 'InternalQuery'
Cannot implicitly convert type 'EntityFramework.Reflection.DynamicProxy' to 'System.Data.Entity.Core.Objects.ObjectQuery<Scholarship.ApplicationHistory>'
Could not load type 'System.Data.Entity.Core.Mapping.EntityContainerMapping'
I've added an issue on the Extended library's github.
Update
I've reinstalled EF and the EF.Extended library with no luck. I am able to use RemoveRange in its place. I am able to create a new project, install the packages, add a model mapped to the same database, and successfully use Delete. Obviously, the problem is in my current solution.
In my solution, I have an ASP.NET project and a regular library project. In the ASP project, a page's code behind calls a method in the library RemoveHistory. The library contains classes for the business logic and data access. Both classes implement interfaces. The actual Delete occurs in the data access class. My model also resides in this library project.
I may be able to create a completely new project and bring everything over, but that will take quite some time. Even if I did, I want to understand why it doesn't work in the first place, so that I don't have to repeat this process.
If you want to delete certain rows do it like that:
Using db As New ScholarshipEntities
db.ApplicationHistories.RemoveRange(db.ApplicationHistories.Where(Function(h) h.HistoryTypeId = 0))
db.SaveChanges()
End Using
If you want to remove single entity do it like that:
Using db As New ScholarshipEntities
db.ApplicationHistories.Remove(db.ApplicationHistories.Single(Function(h) h.HistoryTypeId = 0))
db.SaveChanges()
End Using
I "solved" the issue some time ago. I'll eventually go back to try and reproduce the problem to confirm my suspicions.
There were multiple versions of Entity Framework installed in the solution. This didn't appear to affect basic EF functionality, though I'm sure it did in some subtle, potentially buggy fashion.
Every time the solution was opened, NuGet would state that it couldn't complete uninstallation. Uninstalling and restoring via NuGet was unsuccessful, and the packages had to be deleted manually. Once completely removed, I installed the packages again. This resolved the issue.
I wish I could give a more technical answer, though the basic reason was forgetting to look closer at the packages folder and configuration.