6

Ho due cartelle per le mie migrazioni (AuthContext e UserProfileContext), ognuna ha la propria migrazione e alcuni sql personalizzati da eseguire successivamente per le migrazioni dei dati e quant'altro.Prima migrazione di EF non in esecuzione dopo la distribuzione in Azure

Questo funziona correttamente quando si utilizza la console del gestore pacchetti. I

  1. Ripristina da produzione
  2. Run Update-Database -ConfigurationTypeName Migrations.Auth.Configuration
  3. Run Update-Database -ConfigurationTypeName Migrations.UserProfile.Configuration

Poi tutto è molto felice in il nuovo database, le migrazioni eseguite i dati mescolate dove necessario.

Ho provato a testare le migrazioni di pubblicare pezzo per:

  1. ripristinare la produzione sulla base di dati dev
  2. stringa di connessione unico (tutti i contesti usano lo stesso) indicato a dev banca dati
  3. Pubblica azzurro sito web
  4. controllato la scatola per Applica codice prime migrazioni
  5. selezionate che stringa di connessione singola

Ok, ha pubblicato bene; tuttavia, quando sono andato a vedere il database, non è successo niente! Non ha creato le tabelle, le colonne o gli spostamenti di dati necessari.

TLDR; Codice prime migrazioni non sono in esecuzione, dopo la pubblicazione di Azure

Update 1 Ho provato qualsiasi combinazione dei seguenti: una sola stringa di connessione singola in modo da sto indovinando che non è il problema, ed eseguire migrazioni fa controllato. enter image description here

Al momento della pubblicazione, l'API viene eseguita ma non vengono apportate modifiche al database. Ho pensato che forse avevo bisogno di colpirlo per primo, ma ho solo degli errori casuali quando provo a usare l'api (che ora si basa ovviamente sulla nuova configurazione del database), e il database non è ancora cambiato.

Ho visto un paio di riferimenti là fuori sulla necessità di aggiungere qualcosa alla mia classe di avvio, ma non sono sicuro di come procedere.

Update 2 ho risolto un problema aggiunto "Persiste la sicurezza Info = True" alla mia stringa di connessione. Ora si collega effettivamente al database e chiama la mia API; tuttavia, nessuna migrazione è in esecuzione. Ho collegato il debugger all'ambiente di sviluppo di Azure e ho fatto un passo ... nella mia prima chiamata al database passo nella classe Configuration per la Migrazione in questione, quindi barfs e I non è in grado di rintracciare l'errore.

public Configuration() 
{ 
    AutomaticMigrationsEnabled = false; 
    MigrationsDirectory = @"Migrations\Auth"; 
    ContextKey = "AuthContext"; 
} 

Update 3

Va bene, scavato verso il basso e la prima volta che colpisce il database stiamo erroring. Sì, questo ha senso dal momento che il modello è cambiato, ma ho migrazioni sul posto, abilitato e controllato! Anche in questo caso, funziona benissimo durante l'esecuzione di "Update-Database" dalla console di gestione dei pacchetti, ma non quando si usa eseguire codice prime migrazioni durante la pubblicazione di Azure

Il modello backup contesto 'AuthContext' è cambiato da quando il database era creato. Prendi in considerazione l'utilizzo di Code First Migrations per aggiornare il database (http://go.microsoft.com/fwlink/?LinkId=238269).

Update 4 Ok ho trovato il problema principale qui. VS sta configurando l'attributo web.config aggiuntivo per databaseInitializer su uno solo dei miei contesti di database, quello non menzionato viene in effetti colpito prima dalla mia app.

Quindi ora devo capire come farlo includere più contesti, o combinare tutte le mie cose in un unico contesto.

+0

Hai preso al ook questo post http://blogs.msdn.com/b/webdev/archive/2014/04/09/ef-code-first-migrations-deployment-to-an-azure-cloud-service.aspx, sembra potrebbe essere necessario aggiungere codice al codice Application_Start di Global.asax –

+0

@JWGrazie, l'ho visto, è specifico per Azure Cloud Service e sto usando il sito Web di Azure, per il quale presumibilmente non hai bisogno di fare nulla di più ... –

+0

Penso che devi assicurarti che il codice di migrazione db sia eseguito non importa che tipo di progetto sia. –

risposta

3

Risolto! Per riepilogare la soluzione per i posteri:

Abilita il codice Prima le migrazioni li abilita solo per una stringa di connessione di base per ogni casella di controllo selezionata, indipendentemente da quanti contesti hanno migrazioni contro quella stringa di connessione di base. Quindi nel mio caso ho scomposto i due in questione in due diverse stringhe di connessione.

Poi ho riscontrato altri errori e ho identificato che se si sta modificando la stringa di connessione di base sull'identità del backup del modello asp è necessario includere (una volta pubblicare) la base di bandiera aggiuntiva ("AuthContext", throwIfV1Schema: false)

10

La risposta a questo post non è molto dettagliata.

Questo articolo spiega che cosa ho dovuto fare per risolvere un problema simile a questo: https://blogs.msdn.microsoft.com/webdev/2014/04/08/ef-code-first-migrations-deployment-to-an-azure-cloud-service/

sarò o meno descrivere i passi ho dovuto prendere sotto:

Fase 1 Aggiungi la tua stringhe di connessione ai tuoi dbContexts, nella mia situazione, erano entrambi uguali.

enter image description here

Fase 2 Aggiungi questo al vostro web.config

<appSettings> 
    <add key="MigrateDatabaseToLatestVersion" value="true"/> 
    </appSettings> 

Fase 3 e aggiungere questo al fondo dei tuoi global.asax.cs/Startup.cs (Avvio OWIN)

var configuration = new Migrations.Configuration(); 
    var migrator = new DbMigrator(configuration); 
    migrator.Update(); 
+0

Non riesco a vedere la sezione DATI nella mia assistenza per la pubblicazione ma ho comunque lavorato grazie! – Daniel

+1

Eccellente. Ho dovuto aggiungere il codice che hai menzionato per far richiamare il mio metodo Seed all'avvio. Grazie mille, ho passato ore a cercare di capirlo. – rolls

+0

Grazie per questo! La soluzione ha funzionato nel progetto di codice del server Xamarin Forms di esempio generato da Azure. Invece di aggiungere a global.asax.cs (perché non ne ho uno) ho aggiunto il codice al metodo ConfigureMobileApp() in Startup.MobileApp.cs. –