ef-migrations

My solution contains: FooBarAsp , an asp project (provides a UI for the application) FooBar , a class library (the application) FooBar.Tests , a test project (tests the application) FooBar uses EF 6 Code First, and contains a number of models, and a DataContext . FooBarAsp uses Microsoft's Identity framework for user authentication, and has an ApplicationDbContext . Both contexts play nice and work as expected. Global.asax.cs should execute MigrateDatabaseToLatestVersion (right?). FooBar.Tests should execute DropCreateDatabaseAlways and won't care about migrations (right?). Should I

We have a database schema with ~200 tables. Model snapshot (Migration.Designer.cs) which is created for each migration is ~20K lines. So, having quite a number of migrations really slows down our build on CI (with ~30 migrations building a solution takes 6 minutes with migrations or 4 minutes without them). So, to the question: is it safe to delete model snapshots for old migrations (that we know we will never Revert)? Are model snapshots used for anything else except Revert-Migration? Are model snapshots used for anything else except Revert-Migration? Yes. There are a few edge cases where it

Which is the command to recreate or drop the database when using Entity Framework Migrations, not Initializers ? What should I write on the package manager console ? COMMENT : I'm looking for some command that gives me the same functionality as Database.SetInitializer<>(new DropCreateDatabaseIfModelChanges<>()); but with the migrations approach. You can get the same behavior with Migrations by using automatic migrations. PM> enable-migrations -EnableAutomaticMigrations In Configuration.cs in the constructor, make sure automatic migrations and allow data loss are set to true... public

I have a User model and a Event model in my project. The Event has a creator(User) and has participant(Users) so Event has a one-to-many relationship with User and also a many-to-many relationship to the same table. I had first the one-to-many relationship like this: Public class Event { ... public int CreatedById { get; set; } public virtual User CreatedBy { get; set; } ... } Then when I added the many-to-many relationship the migration doesn't generate the many to many relationship: Public class User { ... public virtual ICollection<Event> Events { get; set; } ... } Public class Event { ...

We are using code first migrations to keep our database and model in sync. At the moment we have the version number as name for the migration which clearly doesn't work out. The problem is that multiple migrations with the same name where created by different developers independent of each other for their local database. This led to some weird behavior as the IMigrationMetadata.Id was different because of the time stamp but the classes are partial with the same name. What is the way to go to call these migrations? The examples are always ridiculously oversimplified: e.g. adding a property

I am having the following error after typing update-database: Cannot create more than one clustered index on table 'dbo.AppUsers'. Drop the existing clustered index 'PK_dbo.AppUsers' before creating another. I am working on an Azure mobile service. I have three data models: public class AppUser : EntityData { public string Username { get; set; } public virtual ICollection<RatingItem> userRatings { get; set; } } public class PlaceItem : EntityData { public string PlaceName { get; set; } public int Group { get; set; } public string XCoordinate { get; set; } public string YCoordinate { get; set;

FACTS: net core 2.0 project entity framework (code first) different appsettings.json file for different environments I utilize Package Manager Console to generate my DB scripts (Add-Migration, Update-Database) If I run PM>"Get-DbContext" it brings back info pulled from my appsettings.Development.json file GREAT, that's what I want most of the time! But how do I tell it to pull db variables from appsettings.Staging.json instead of development for PM commands? I tried creating new launchSettings.json profiles and setting "ASPNETCORE_ENVIRONMENT": "Staging" but everything seems to respect that