2016-09-21 18 views
5

Mamy zainstalowaną aplikację internetową (Net Core 1.0.0-preview2-003121) do usługi aplikacji Azure i staramy się wdrożyć migracje.EF Core (1.0.0) Migracje w usługach aplikacji Azure

W RC1/2 można było wykonać migracje z plikiem ef.cmd, która wydawała się być automagicznie tam, mianowicie możemy użyć tego pliku do uruchomienia

dnx ef database update 

ale ten zniknął.

dotnet ef nie jest zainstalowany w samej usłudze aplikacji Azure, więc nie jest to opcja.

Jakieś pomysły, które nie wymagają uruchamiania migracji z kodu/wdrażania ich ze studia wizualnego?

Staramy się zbudować ciągły potok wdrażania i wolałbym uniknąć wymuszania wdrażania migracji z kodu.

MY google-fu jest wyraźnie braku mnie tutaj, gdyż nie może dla życia mnie znaleźć coś i nie mogę być jedynym próbuje wdrożyć migracje na serwerze

TIA

+0

CLI zmieniły. https://docs.efproject.net/en/latest/miscellaneous/cli/dotnet.html – Ben

+0

@Ben rzeczywiście. Nawiązałem do tego faktu na stanowisku, wspominając, że dotnet ef nie jest zainstalowany, prawdopodobnie nie jest jasne, co miałem na myśli w samej usłudze aplikacji azure, a nie mojej maszynie. – ManyRootsofAllEvil

Odpowiedz

2

Co skończyło się robi jest:

na stronie kompilacji możemy wygenerować skrypt tworzenia bazy danych idempotent:

dotnet ef migrations script --idempotent --output migrations.sql --context ApplicationContext 

Gdzie ApplicationContext to nazwa yo ur Kontekst EF i migrations.sql to nazwa pliku skryptu sql.

Następnie na stronie rozmieszczania mamy mały skrypt powershell, który skutecznie uruchamia skrypt migrations.sql

param(
[Parameter(Mandatory)] 
[string]$server, 
[Parameter(Mandatory)] 
[string]$dbname, 
[Parameter(Mandatory)] 
[string]$dbadmin, 
[Parameter(Mandatory)] 
[string]$dbpassword, 
[Parameter(Mandatory)] 
[string]$migrationPath 
) 

function Deploy-Migrations ($migrationPath,$DBSettings) 
{ 
    #Setting up database connection 
    $connection = New-Object System.Data.SqlClient.SqlConnection 
    $connection.ConnectionString = [string]::Format("Data Source=tcp:{0}.database.windows.net,1433;Initial Catalog={1};User Id={2}@{0};Password={3};MultipleActiveResultSets=True", $DBsettings['sqlServerName'], $DBsettings['databasename'],$DBsettings['adminAccount'], $DBsettings['adminPassword']) 

    try 
    { 
     $connection.Open(); 

     $SqlCmd = New-Object System.Data.SqlClient.SqlCommand 
     $SqlCmd.Connection = $connection 
     $query = Get-Content $migrationPath 
     $sqlCmd.CommandText = $query.Replace("GO","") # This is required to prevent "syntax" complaints 
     $sqlCmd.ExecuteNonQuery() 

     Write-Host "Migration Deployed" 
    } 
    Catch 
    { 

     Write-Error "oops ... PAnic ... $($_.Exception.Message) on $($_.Exception.ItemName)" 
     break 
    } 
    Finally 
    { 
     $connection.Close() 
    } 
} 

$DBSettings = @{"sqlServerName"=$server; "databasename"=$dbname; "adminAccount"=$dbadmin; "adminPassword"=$dbpassword } 

Deploy-Migrations $migrationPath $DBSettings 
+2

Dzięki za to. Czasami praca z ASP.NET Core sprawia, że ​​czuję się jakbym była jedyną osobą na świecie, która kiedykolwiek z niej korzystała. Skrypty SQL to jest .... –

Powiązane problemy