EntityFramework Code-First benutzerdefinierte Verbindungszeichenfolge und Migrationen

Wenn Ihr die migration funktioniert nicht richtig, versuchen Sie Database.Initialize(true) im DbContext-ctor.

public CustomContext(DbConnection connection)
: base(connection, true)    
{    
        Database.Initialize(true);    
}    

Ich habe ähnliches problem mit Migrationen. Und in meiner Lösung habe ich immer festlegen von Datenbank-Initialisierung in ctor, wie unten

public CustomContext(DbConnection connection)
: base(connection, true)    
{    
        Database.SetInitializer(new CustomInitializer());
        Database.Initialize(true);    
}    

In benutzerdefinierte Initialisierung implementieren Sie InitalizeDatabase(CustomContex context) Methode, zB.

class CustomInitializer : IDatabaseInitializer<CustomContext>
{
    public void InitializeDatabase(CustomContext context)
    {
        if (!context.Database.Exists || !context.Database.CompatibleWithModel(false))
        {
            var configuration = new Configuration();
            var migrator = new DbMigrator(configuration);
            migrator.Configuration.TargetDatabase = new DbConnectionInfo(context.Database.Connection.ConnectionString, "System.Data.SqlClient");
            var migrations = migrator.GetPendingMigrations();
            if (migrations.Any())
            {
                var scriptor = new MigratorScriptingDecorator(migrator);
                string script = scriptor.ScriptUpdate(null, migrations.Last());
                if (!String.IsNullOrEmpty(script))
                {
                    context.Database.ExecuteSqlCommand(script);
                }
            }
        }
    }
}

AKTUALISIERT

InformationsquelleAutor der Antwort rraszewski

Ich in der Lage, wechseln zwischen den verbindungen mit der folgenden Technik

1) Haben Sie mehrere connection-string als Namen definiert in der app.config.

2) ein Konstruktor, in dem Kontext, der nimmt den Namen der Verbindungszeichenfolge

public Context(string connStringName)
        : base(connStringName)
    {

    }

3) die Create-Methode für den Kontext - und machen es in der Lage, erhalten den Namen der Verbindung ein ( mit ein bisschen trick )

  public class ContextFactory : IDbContextFactory<Context>
  {
    public Context Create()
    {
        var s = (string)AppDomain.CurrentDomain.GetData("ConnectionStringName");
        var context = new Context(s);
        return context;
    }
}

4) Meine migration-Konfiguration ....

 public sealed class Configuration : DbMigrationsConfiguration<SBD.Syrius.DataLayer.Context>
{
   etc
}

5) eine Funktion zum erstellen von Rahmen.

 private static Context MyCreateContext(string connectionStringName )
    {
        //so that we can get the connection string name to the context create method 
       AppDomain.CurrentDomain.SetData("ConnectionStringName", connectionStringName);

        //hook up the Migrations configuration
        Database.SetInitializer(new MigrateDatabaseToLatestVersion<Context, Configuration>());

        //force callback by accessing database
        var db = new Context(connectionStringName);
        var site = db.Sites.FirstOrDefault()  //something to access the database

        return db;
    }

InformationsquelleAutor der Antwort Kirsten Greed

Für Migrationen können Sie entweder (1) nutzen MigrateDatabaseToLatestVersion die kick-in automatisch, wenn Sie starten Sie mit einer der Personen in Ihrem Kontext oder (2) verwenden DbMigrator explizit sagen, EF, kick-off der migration. Der Vorteil von (2) ist, dass Sie nicht haben, um führen Sie einen dummy-Betrieb (wie AddJunk @philsoady Beispiel), und man könnte sogar MigratorScriptingDecorator wenn Sie wollte, extrahieren Sie die migration zu SQL (siehe Beispiel 2 im code)

Den trick mit (2) scheint zu sein, sicherzustellen, dass die gleiche Verbindungszeichenfolge verwendet wird konsequent von Ihrem DbMigrationsConfiguration und DbContext Klassen. Beachten Sie, dass mehrere Kontexten instanziiert werden im Laufe des DbMigration.Update - alle rufen Sie das Kontext-Standard-Konstruktor (so watch out, wenn Sie mehr als einen Konstruktor). Sie haben auch 2 Optionen hier können Sie ein connection string name in der app.config (aber dann kann man nicht programmatisch definieren Sie den connection-string) oder build\fest\load etc... eine komplette connection string. Siehe die Kommentare im code unten.

Getestet EF 6.0.1 & 6.0.2

using System;
using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;
using System.Data.Entity;
using System.Data.Entity.Infrastructure;
using System.Data.Entity.Migrations;
using System.Data.Entity.Migrations.Infrastructure;

namespace ConsoleApplication1
{
    //Models
    public class Foo
    {
        [Key]
        public int Id { get; set; }
        public string Column1 { get; set; }
        public string Column2 { get; set; }
    }

    //Configuration
    public class Configuration : DbMigrationsConfiguration<Context>
    {
        public static string StaticConnectionString; //use connection string

        public Configuration()
        {
            AutomaticMigrationsEnabled = true;
            AutomaticMigrationDataLossAllowed = true;
            TargetDatabase = new DbConnectionInfo(StaticConnectionString, "System.Data.SqlClient"); //use connection string
            //TargetDatabase = new DbConnectionInfo("ConnectionStringName"); //use connection string name in app.config
        }

        protected override void Seed(Context context)
        {
        }
    }

    //Context
    public class Context : DbContext
    {
        public Context()
            //: base("ConnectionStringName") //use connection string name in app.config
            : base(ConsoleApplication1.Configuration.StaticConnectionString) //use connection string
        {
        }

        public IDbSet<Foo> Foos { get; set; }
    }

    //App
    class Program
    {
        static void Main(string[] args)
        {
            //Example 1 - migrate to test1 DB
            Configuration.StaticConnectionString = "Data Source=localhost;Initial Catalog=test1;Integrated Security=True;MultipleActiveResultSets=True";
            var configuration = new Configuration();
            var migrator = new DbMigrator(configuration);
            migrator.Update();
            Console.WriteLine("Migration 1 complete");

            //Example 2 - create migrate SQL and migrate to test2 DB
            //NOTE: You can't do this if you use a connection string name in app.config
            //Generate migrate sql script for migration to test2 DB
            Configuration.StaticConnectionString = "Data Source=localhost;Initial Catalog=test2;Integrated Security=True;MultipleActiveResultSets=True";
            configuration = new Configuration();
            migrator = new DbMigrator(configuration);
            var scriptor = new MigratorScriptingDecorator(migrator);
            string sql = scriptor.ScriptUpdate(null, null);
            Console.WriteLine("Migration 2 SQL:\n" + sql);

            //Perform migration to test2 DB
            configuration = new Configuration();
            migrator = new DbMigrator(configuration);
            migrator.Update();
            Console.WriteLine("Migration 2 complete");
        }
    }
}

InformationsquelleAutor der Antwort Ilan

Wollte ich automatisch migrieren, wenn die Ausführung im DEBUG zu machen es einfach für die devs (die Produktion installer wird die Migrationen normal) aber hatte das gleiche problem, ein code-angegeben connection-string wird ignoriert, wenn die Migration.

Mein Ansatz war, um daraus die Migration von Kontexten aus diesem generic die Griffe "speichern" Sie die Verbindungszeichenfolge:

public class MigrateInitializeContext<TDbContext, TMigrationsConfiguration> : DbContext
    where TDbContext : DbContext
    where TMigrationsConfiguration : DbMigrationsConfiguration<TDbContext>, new()
{
    //ReSharper disable once StaticFieldInGenericType
    private static string nameOrConnectionString = typeof(TDbContext).Name;

    static MigrateInitializeContext()
    {
        Database.SetInitializer(new MigrateDatabaseToLatestVersion<TDbContext, TMigrationsConfiguration>());
    }

    protected MigrateInitializeContext(string nameOrConnectionString)
        : base(nameOrConnectionString)
    {
        MigrateInitializeContext<TDbContext,TMigrationsConfiguration>.nameOrConnectionString = nameOrConnectionString;
    }

    protected MigrateInitializeContext() : base(nameOrConnectionString)
    {
    }
}

ReSharper Warnung ist, da statische Felder in einer generischen Klasse sind nur statische pro konkretem Typ in unserem Fall ist genauwas wir wollen.

Zusammenhänge sind definiert als:

public class MyContext : MigrateInitializeContext<MyContext, Migrations.Configuration>
{
    public MyContext()
    {
    }

    public MyContext(string nameOrConnectionString)
        : base(nameOrConnectionString)
    {
    }

    public virtual DbSet<MyType> MyTypes { get; set; }
}

welche Regel verwendet werden kann.

InformationsquelleAutor der Antwort PeteB