Il modello che supporta il contesto è cambiato da quando è stato creato il database

Il messaggio di errore:

“Il modello che supportava il contesto” AddressBook “è stato modificato da quando è stato creato il database. Eliminare o aggiornare manualmente il database o chiamare Database.SetInitializer con un’istanza IDatabaseInitializer. Ad esempio, la strategia RecreateDatabaseIfModelChanges eliminerà e ricrea automaticamente il database e facoltativamente seminarlo con nuovi dati. ”

Sto cercando di utilizzare la funzionalità code-first e il seguente è ciò che ho scritto:

var modelBuilder = new ModelBuilder(); var model = modelBuilder.CreateModel(); using (AddressBook context = new AddressBook(model)) { var contact = new Contact { ContactID = 10000, FirstName = "Brian", LastName = "Lara", ModifiedDate = DateTime.Now, AddDate = DateTime.Now, Title = "Mr." }; context.contacts.Add(contact); int result = context.SaveChanges(); Console.WriteLine("Result :- "+ result.ToString()); } 

La class di contesto:

 public class AddressBook : DbContext { public AddressBook() { } public AddressBook(DbModel AddressBook) : base(AddressBook) { } public DbSet contacts { get; set; } public DbSet
Addresses { get; set; } }

e la stringa di connessione:

       

Quindi, il nome del database è “AddressBook” e l’errore si verifica quando tento di aggiungere l’object contatto al contesto. Mi sto perdendo qualcosa qui?

Adesso è:

 protected override void OnModelCreating(DbModelBuilder modelBuilder) { Database.SetInitializer(null); base.OnModelCreating(modelBuilder); } 

nel tuo file YourDbContext.cs.

Ecco alcune informazioni dal blog di Scott Gu pubblicate da Jeff su ciò che sta effettivamente avvenendo:

Per coloro che stanno vedendo questa eccezione:

“Il modello che supportava il contesto” Produzione “è stato modificato da quando è stato creato il database. Eliminare o aggiornare manualmente il database oppure chiamare Database.SetInitializer con un’istanza IDatabaseInitializer .”

Ecco cosa sta succedendo e cosa fare al riguardo:

Quando un modello viene creato per la prima volta, eseguiamo un DatabaseInitializer per fare cose come creare il database se non c’è o aggiungere i dati di seed. Il DatabaseInitializer predefinito tenta di confrontare lo schema del database necessario per utilizzare il modello con un hash dello schema memorizzato in una tabella EdmMetadata che viene creata con un database (quando Code First è quello che crea il database). I database esistenti non avranno la tabella EdmMetadata e quindi non avranno l’hash … e l’implementazione oggi verrà lanciata se manca quella tabella. Lavoreremo su come cambiare questo comportamento prima di spedire la versione fial dal momento che è l’impostazione predefinita. Fino ad allora, i database esistenti non hanno generalmente bisogno di alcun inizializzatore del database in modo che possa essere distriggersto per il proprio tipo di contesto chiamando:

 Database.SetInitializer(null); 

Jeff

Per Entity Framework 5.0.0.0 – 6.1.3

Vuoi davvero fare quanto segue:

 1. using System.Data.Entity; to startup file (console app --> Program.cs / mvc --> global.asax 2. Database.SetInitializer(null); 

Sì, Matt Frear è corretto. UPDATE -EDIT: Caveat è che sono d’accordo con gli altri in quanto invece di aggiungere questo codice a global.asax aggiunto alla tua class DbContext

 protected override void OnModelCreating(DbModelBuilder modelBuilder) { // other code Database.SetInitializer(null); // more code } 

Come altri hanno menzionato, questo è utile anche per gestire il test dell’unità.

Attualmente sto usando questo con Entity Framework 6.1.3 /.net 4.6.1

Questa correzione non funziona più dopo CTP5.

Devi fare Database.SetInitializer(null);

Ho appena scoperto la risposta e ho pensato di aggiornare qui. Basta fare quanto segue.

 public class AddressBook: DbContext { protected override void OnModelCreating(ModelBuilder modelBuilder) { modelBuilder.IncludeMetadataInDatabase = false; } } 

Basta eseguire il comando follletg sql in SQL Server Management Studio:

 delete FROM [dbo].[__MigrationHistory] 

Oppure puoi inserire questa linea nel tuo file Global.asax.cs in Application_Start ():

 System.Data.Entity.Database.SetInitializer(new System.Data.Entity.DropCreateDatabaseIfModelChanges()); 

Assicurati di modificare ProjectName.Path.Context nello spazio dei nomi e nel contesto. Se si utilizza prima il codice, questo eliminerà e creerà un nuovo database ogni volta che verranno apportate modifiche allo schema.

Ho trascorso molti giorni per risolvere questo problema, analizzato molti post diversi e provato molte opzioni e infine risolto. Questi 2 progetti nella mia soluzione utilizzano le migrazioni di primo codice EF:

  • Applicazione console “DataModel” che utilizza principalmente come assembly che contiene tutte le mie prime quadro di codice, DbContext, Mirgations e repository generico. Ho incluso in questo progetto un file di database locale vuoto separato (nella cartella DataModel / App_Data) per poter generare migrazioni dalla console di Package Manager.
  • WebApi, che fa riferimento al progetto DataModel e utilizza il file di database locale dalla cartella WebApi / App_Data, che non è incluso nel progetto

Ho ricevuto questo errore quando richiesto WebApi …

Il mio ambiente:

  • Windows 8.1 x64
  • Visual Studio 2015 Professional con aggiornamento 1
  • tutti i miei progetti mirati per .NET Framework 4.6.1
  • EntityFramework 6.1.3 da NuGet

Qui ho raccolto tutte le osservazioni che dovresti prestare attenzione e tutte le condizioni / requisiti che devono essere soddisfatti, per evitare un’eccezione menzionata:

  1. È necessario utilizzare solo una versione del pacchetto Nuget di EntityFramework per tutti i progetti nella soluzione.
  2. Il database, creato eseguendo in sequenza tutti gli script di migrazione, dovrebbe avere la stessa struttura / schema del database di destinazione e corrispondere al modello di entity framework. Seguendo 3 cose devono esattamente corrispondere / riflettere / abbinarsi tra loro:
    • Tutto il tuo script di migrazione fino all’ultimo
    • Stato del codice della prima quadro del codice corrente (DbContext, entity framework)
    • Database di destinazione
  3. Il database di destinazione (file mdf) deve essere aggiornato / corrispondere fino all’ultimo script di migrazione. Verificare che la tabella “__MigrationHistory” nel database di destinazione contenga i record per tutti gli script di migrazione in uso, significa che tutti gli script di migrazione sono stati applicati correttamente a quel database. Vi consiglio di utilizzare Visual Studio per la generazione di codice corretto per prime entity framework e contesto che corrisponde al vostro database, Progetto -> Aggiungi nuovo elemento -> ADO.NET Entity Data Model -> Code First dal database: Naturalmente, in alternativa, se non si dispone di un database, è ansible scrivere manualmente il modello (codice prima quadro e contesto) e quindi generare la migrazione iniziale e il database.
  4. Nome della stringa di connessione es. MyConnectionString nel file di configurazione del progetto di avvio (Web.config / App.config):

          

    dovrebbe essere uguale al parametro passato nel costruttore del tuo DbContext:

      public partial class MyDbContext : DbContext { public MyDbContext() : base("name=MyConnectionString"){} ... 
  5. Prima di utilizzare la console di Package Manager , assicurarsi di utilizzare il database corretto per l’aggiornamento o generare la migrazione e il progetto necessario viene impostato come progetto di avvio della soluzione. Per la connessione al database utilizzerà la stringa di connessione da quel file .config, che nel progetto, è impostato come progetto di avvio.
  6. E il principale, che ha risolto il mio problema: è strano, ma nella mia cartella WebApi / bin DataModel.exe era vecchio, non aggiornato dall’ultima build. Poiché le migrazioni sono state incorporate nel mio assieme DataModel.exe, il mio database aggiornato di WebApi utilizzava vecchie mirazioni. Ero confuso perché dopo aver aggiornato il database in WebApi non corrisponde all’ultimo script di migrazione da DataModel. Il codice seguente crea automaticamente (se non esiste) o aggiornamenti al database locale di migrazione più recente nella mia cartella WebApi / App_Data.

      public class WebApiApplication : System.Web.HttpApplication { protected void Application_Start() { Database.SetInitializer(new MigrateDatabaseToLatestVersion()); ... 

    Ho provato a pulire e ribuild la soluzione, ma non mi ha aiutato, ho rimosso completamente le cartelle bin e obj da WebApi, i file di database cancellati da WebApi / App_Data, costruito, riavviato WebApi, fatto richiesta, creato database corretto – inizializzazione pigra (usando righe sopra), che corrisponde all’ultima migrazione e l’eccezione non è stata più visualizzata. Quindi, questo potrebbe risolvere il tuo problema:

    1. rimuovere manualmente bin, cartelle obj dal progetto di avvio (che genera / aggiorna il database)
    2. crea il tuo progetto di avvio o meglio pulisci e ricostruisci tutte le soluzioni.
    3. ricreare il database avviando il progetto (eseguirà le righe sopra) o utilizzare il comando “update-database” della Console di gestione pacchetti.
    4. verificare manualmente se db e __MirgationHistory generati corrispondono all’ultimo script di migrazione.

Per me, con l’aggiornamento alla 4.3.1, ho solo troncato la tabella EdmMetaData o semplicemente cancellato completamente.

Per gli sviluppatori VB.NET:

Aggiungi la seguente riga al file Glabal.asax.vb, alla fine del metodo Application_Start ()

 Database.SetInitializer(Of ApplicationDbContext)(Nothing) 

Cambia ApplicationDbContext nel tuo specifico contesto Db.

Ho avuto questo problema e si è scoperto che un progetto puntava a SQLExpress ma quello con il problema stava puntando a LocalDb. (nel rispettivo web.config). Silly supervisione, ma vale la pena notare qui nel caso in cui qualcun altro è la risoluzione di questo problema.

Ho avuto lo stesso problema: aggiungere nuovamente la migrazione e aggiornare il database non ha funzionato e nessuna delle risposte sopra sembrava corretta. Poi l’ispirazione mi ha colpito – sto usando più livelli (un web, un dato e un business). Il livello dati ha il contesto e tutti i modelli. Il livello Web non ha mai generato questa eccezione: era il livello aziendale (che ho impostato come applicazione console per test e debug). Risulta che il livello aziendale non stava usando la giusta stringa di connessione per ottenere il db e creare il contesto. Così ho aggiunto la stringa di connessione alla configurazione dell’app del livello aziendale (e del livello dati) e viola funziona. Mettetelo qui per gli altri che potrebbero incontrare lo stesso problema.

Io uso il metodo Database.CompatibleWithModel (disponibile in EF5) per verificare se il modello e il DB coincidono prima di usarlo. Chiamo questo metodo solo dopo aver creato il contesto …

  // test the context to see if the model is out of sync with the db... if (!MyContext.Database.CompatibleWithModel(true)) { // delete the old version of the database... if (File.Exists(databaseFileName)) File.Delete(databaseFileName); MyContext.Database.Initialize(true); // re-populate database } 

Significa che ci sono stati alcuni cambiamenti nel contesto che non sono stati eseguiti. Eseguire prima Add-Migration per generare le modifiche che abbiamo eseguito (le modifiche che potrebbero non essere a conoscenza) e quindi eseguire Update-Database

Ho avuto lo stesso problema quando abbiamo utilizzato un database per due applicazioni. L’impostazione disableDatabaseInitialization="true" nella sezione del tipo di contesto funziona per me.

          

Vedi ulteriori dettagli https://msdn.microsoft.com/en-us/data/jj556606.aspx

Nel caso qualcuno abbia lo stesso scenario del mio.

Ho database prima EF e allo stesso tempo utilizzo dell’id quadro asp.net

quindi ho due connectionStrings nel mio webconfig e non ci sono problemi con questo. È successo che ho creato / eseguito gli script per generare manualmente le tabelle di id quadro di asp.net che non dovrei.

quindi DROP prima tutte le tabelle di identity framework di asp.net create manualmente dall’utente / dagli script.

 DROP TABLE __MigrationHistory DROP TABLE AspNetRoles DROP TABLE AspNetUserClaims DROP TABLE AspNetUserLogins DROP TABLE AspNetUserRoles DROP TABLE AspNetUsers 

Dopo alcune ricerche su questo argomento, ho scoperto che l’errore si è verificato in sostanza se si dispone di un’istanza di db creata precedentemente sul proprio server SQL Express locale. Quindi ogni volta che si hanno aggiornamenti su db e si tenta di aggiornare il db / eseguire un codice su db senza eseguire il comando Update Database usando la Package Manager Console ; prima di tutto, devi eliminare manualmente il db precedente sul nostro sql express locale.

Inoltre, questa soluzione funziona a meno che non si abbia AutomaticMigrationsEnabled = false; nella tua configurazione.

Se lavori con un sistema di controllo versione (git, svn, ecc.) E alcuni altri sviluppatori aggiornano gli oggetti db nella fase di produzione, questo errore aumenta ogni volta che aggiorni il tuo codice base ed esegui l’applicazione.

Come detto sopra, ci sono alcune soluzioni per questo su base di codice. Tuttavia, questo è il più pratico in alcuni casi.

Sto leggendo anche il libro Pro ASP.NET MVC 4 e ho riscontrato lo stesso problema che avevi. Per me, ho iniziato ad avere il problema dopo aver apportato le modifiche prescritte nella sezione “Aggiunta di validazione del modello” del libro. Il modo in cui ho risolto il problema è spostando il mio database dal localdb al server SQL Server 2012 completo. (A proposito, so che sono fortunato a passare alla versione completa, quindi non odiarmi. ;-))) Deve esserci qualcosa con la comunicazione al db che sta causando il problema.

Controlla i seguenti passaggi

  1. Database.SetInitializer (null); -> in Global.asax.cs

2.

  1. il nome della class Context deve coincidere con il controllo

Modificare Global.asax.cs , incluso l’evento Application_Start con:

 Database.SetInitializer( new DropCreateDatabaseIfModelChanges()); 

Questo errore può indicare un problema con la stringa di connessione e se il nome della stringa di connessione corrisponde alla dichiarazione di contesto del database.

Ho avuto questo errore perché avevo erroneamente chiamato il database locale (errore stupido) e il nome della stringa di connessione in web.config di “DefaultConnection” non corrispondeva a MyDbContext, ad es.

 public MyDbContext(): base("DefaultConnection") {}   

Prova a utilizzare Database SetInitializer che appartiene a System.Data.Entity;

In Global.asax

 protected void Application_Start() { Database.SetInitializer(new DropCreateDatabaseIfModelChanges()); } 

Questo creerà un nuovo database ogni volta che il tuo modello sarà cambiato.Ma il tuo database sarebbe vuoto.Per riempirlo con dati fittizi puoi usare Semina. Che puoi implementare come:

Semina ::

 protected void Application_Start() { Database.SetInitializer(new AddressBookInitializer()); ----rest code--- } public class AddressBookInitializer : DropCreateDatabaseIfModelChanges { protected override void Seed(AddressBook context) { context.yourmodel.Add( { }); base.Seed(context); } } 

È strano, ma tutte le risposte qui erano inutili per me. Per me ha funzionato l’inizializzatore

MigrateDatabaseToLatestVersion

Ecco la mia soluzione (lo so, può essere molto più semplice, ma è come lo uso):

 class MyDbMigrateToLatest : MigrateDatabaseToLatestVersion { } public class MyDbContext: DbContext { public MyDbContext() : base("DbName") { SetInitializer(); } public MyDbContext(string connString) : base(connString) { SetInitializer(); } private static void SetInitializer() { if (ConfigurationManager.AppSettings["RebuildDatabaseOnStart"] == "true") Database.SetInitializer(new MyDbInitializerForTesting()); else Database.SetInitializer(new MyDbMigrateToLatest()); } } public sealed class Configuration : DbMigrationsConfiguration { public Configuration() { AutomaticMigrationsEnabled = true; } protected override void Seed(MyDbContext context) { // Whatever } } 

MyDbInitializerForTesting eredita appena da DropCreateDatabaseAlways quindi in alcuni casi specifici (testing), viene ricostruito l’intero database. Altrimenti viene migrato alla versione più recente.

La mia fonte: https://msdn.microsoft.com/en-us/data/jj591621.aspx#specific

Buon suggerimento, tuttavia, non così preciso in tutti i casi. Ne capisco uno. È necessario assicurarsi di eseguire “enable-migrations” utilizzando PM windows in Visual Studio e la cartella di migrazione verrà aggiunta al progetto.

Assicurati che i due file di class c # aggiunti alla cartella su conterranno tutti i tuoi modelli e le loro rispettive proprietà.

Se hai tutto ciò che costruisce la soluzione e pubblica per la distribuzione.

La logica è che i metadati esistenti non possono essere sovrascritti perché l’applicazione non ha metadati per sostituire la corrente. Di conseguenza ottieni questo errore “Il modello che supporta il contesto è cambiato da quando è stato creato il database”

Nessuna di queste soluzioni funzionerebbe per noi (oltre a disabilitare completamente il controllo dello schema). Alla fine abbiamo avuto un miss-match nella nostra versione di Newtonsoft.json

Il nostro AppConfig non è stato aggiornato correttamente:

     

La soluzione era di correggere la versione dell’assembly in quella che stavamo effettivamente distribuendo

     

Crea un inizializzatore di contesto personalizzato:

 public class MyDbContextInitializer : MigrateDatabaseToLatestVersion { public override void InitializeDatabase(MyDbContext context) { bool exists = context.Database.Exists(); base.InitializeDatabase(context); if (!exists) { MyDbSeed.Seed(context); } } } 

Si noti che Migrations.Configuration è una class che genera dalla riga di comando di migrazione in Package Manager Console. Potrebbe essere necessario modificare l’interno del modificatore pubblico della class Migrations.Configuration.

E registralo dal tuo OmModelCreating:

 public partial class MyDbContext : DbContext { protected override void OnModelCreating(DbModelBuilder modelBuilder) { Database.SetInitializer(new MyDbContextInitializer()); //other code for creating model } } 

Qui voglio condividere un altro metodo che impedisce l’errore del backing del modello quando il contesto è cambiato:

1) Apri il tuo file DbContext

2) Aggiungi spazio dei nomi utilizzando Microsoft.AspNet.Identity.EntityFramework;

3) public MyDbContext (): base (“name = MyDbContext”) {Database.SetInitializer (new DropCreateDatabaseAlways ()); }