Mentre questa domanda si basa sul non preoccuparsi dei dati, a volte la manutenzione dei dati è essenziale.
In tal caso, ho scritto un elenco di passaggi su come ripristinare da incubo Entity Framework quando il database ha già tabelle con lo stesso nome qui: Come ripristinare da incubo Entity Framework - il database ha già tabelle con lo stesso nome
Apparentemente ... un moderatore ha ritenuto opportuno eliminare il mio post, quindi lo incollerò qui:
Come recuperare dall'incubo di Entity Framework: il database ha già tabelle con lo stesso nome
Descrizione : Se sei come noi quando il tuo team è nuovo di EF, finirai in uno stato in cui non puoi creare un nuovo database locale o non puoi applicare aggiornamenti al tuo database di produzione. Volete tornare in un ambiente EF pulito e poi attenervi alle basi, ma non potete. Se lo fai funzionare per la produzione, non puoi creare un db locale e se lo fai funzionare per locale, il tuo server di produzione non è sincronizzato. Infine, non si desidera eliminare i dati del server di produzione.
Sintomo : impossibile eseguire Update-Database perché sta tentando di eseguire lo script di creazione e il database ha già tabelle con lo stesso nome.
Messaggio di errore: System.Data.SqlClient.SqlException (0x80131904): esiste già un oggetto denominato '' nel database.
Contesto del problema : EF comprende dove si trova il database corrente rispetto a dove si trova il codice in base a una tabella nel database denominata dbo .__ MigrationHistory. Quando esamina gli Script di migrazione, cerca di riconsiliare dove si trovava l'ultima volta con gli script. Se non ci riesce, cerca solo di applicarli in ordine. Ciò significa che ritorna allo script di creazione iniziale e se si guarda la prima parte del comando UP, sarà la tabella di Creeate per la tabella su cui si è verificato l'errore.
Per capirlo in modo più dettagliato, consiglierei di guardare entrambi i video citati qui:
https://msdn.microsoft.com/en-us/library/dn481501(v=vs.113).aspx
Soluzione : ciò che dobbiamo fare è ingannare EF nel pensare che il database corrente sia aggiornato mentre non si applicano questi comandi CreateTable. Allo stesso tempo, vogliamo ancora che esistano quei comandi in modo da poter creare nuovi database locali.
Passaggio 1: DB di produzione pulito Per
prima cosa, eseguire un backup del proprio db di produzione. In SSMS, fai clic con il pulsante destro del mouse sul database, seleziona "Attività> Esporta applicazione livello dati ..." e segui le istruzioni. Aprire il database di produzione ed eliminare / eliminare la tabella dbo .__ MigrationHistory.
Passaggio 2: pulizia dell'ambiente locale
Aprire la cartella delle migrazioni ed eliminarla. Presumo che tu possa riavere tutto da git se necessario.
Passaggio 3: Ricreare iniziale
In Gestione pacchetti, eseguire "Enable-Migrations" (EF ti chiederà di utilizzare -ContextTypeName se hai più contesti). Esegui "Add-Migration Initial -verbose". Questo creerà lo script iniziale per creare il database da zero in base al codice corrente. Se hai avuto delle operazioni seed nel precedente Configuration.cs, copialo su across.
Step 4: Trick EF
A questo punto, se avessimo eseguito Update-Database , avremmo riscontrato l'errore originale. Quindi, dobbiamo ingannare EF nel pensare che sia aggiornato, senza eseguire questi comandi. Quindi, vai al metodo Su nella migrazione iniziale che hai appena creato e commenta tutto.
Passaggio 5: Database di aggiornamento
Senza codice da eseguire sul processo Up, EF creerà la tabella dbo .__ MigrationHistory con la voce corretta per dire che ha eseguito correttamente questo script. Vai e dai un'occhiata se vuoi. Ora decommenta quel codice e salva. È possibile eseguire nuovamente Update-Database se si desidera verificare che EF sia aggiornato. Non eseguirà il passaggio Up con tutti i comandi CreateTable perché pensa di averlo già fatto.
Passaggio 6: Conferma che EF è REALMENTE aggiornato
Se avevi del codice a cui non erano state ancora applicate migrazioni, questo è quello che ho fatto ...
Esegui "Add-Migration MissingMigrations" Questo creerà praticamente uno script vuoto. Poiché il codice era già presente, in realtà c'erano i comandi corretti per creare queste tabelle nello script di migrazione iniziale, quindi ho appena tagliato il comando CreateTable ed equivalenti nei metodi Su e Giù.
Ora, esegui di nuovo Update-Database e guardalo eseguire il tuo nuovo script di migrazione, creando le tabelle appropriate nel database.
Passaggio 7: confermare nuovamente e confermare.
Costruisci, testa, esegui. Assicurarsi che tutto sia in esecuzione, quindi eseguire il commit delle modifiche.
Passaggio 8: fai sapere al resto del tuo team come procedere.
Quando la persona successiva si aggiorna, EF non saprà che cosa l'ha colpito dato che gli script eseguiti in precedenza non esistono. Ma, supponendo che i database locali possano essere spazzati via e ricreati, tutto va bene. Dovranno eliminare il loro database locale e aggiungere crearlo nuovamente da EF. Se avessero apportato modifiche locali e migrazioni in sospeso, consiglierei di creare nuovamente il loro DB sul master, passare al ramo delle funzionalità e ricreare questi script di migrazione da zero.
DROP DATABASEallora ....