Можно ли использовать беглый миграционный процесс в application_start?

PM> Install-Package FluentMigrator.Tools

Вручную добавьте ссылку на:

packages\FluentMigrator.Tools.1.6.1\tools\AnyCPU\40\FluentMigrator.Runner.dll

Обратите внимание, что имя папки зависит от номера версии, на этом рисунке используется текущая версия 1.6.1. Если вам нужен бегун .NET 3.5, используйте каталог \35\.

public static class Runner
{
    public class MigrationOptions : IMigrationProcessorOptions
    {
        public bool PreviewOnly { get; set; }
        public string ProviderSwitches { get; set; }
        public int Timeout { get; set; }
    }

    public static void MigrateToLatest(string connectionString)
    {
        // var announcer = new NullAnnouncer();
        var announcer = new TextWriterAnnouncer(s => System.Diagnostics.Debug.WriteLine(s));
        var assembly = Assembly.GetExecutingAssembly();

        var migrationContext = new RunnerContext(announcer)
        {
            Namespace = "MyApp.Sql.Migrations"
        };

        var options = new MigrationOptions { PreviewOnly=false, Timeout=60 };
        var factory = 
            new FluentMigrator.Runner.Processors.SqlServer.SqlServer2008ProcessorFactory();

        using (var processor = factory.Create(connectionString, announcer, options))
        { 
            var runner = new MigrationRunner(assembly, migrationContext, processor);
            runner.MigrateUp(true);
        }
    }
}

Обратите внимание, что SqlServer2008ProcessorFactory это настраивается в зависимости от вашей базы данных, есть поддержка: 2000, 2005, 2008, 2012 и 2014.

На самом деле я выполнил миграцию в application_start, однако по этому коду трудно сказать, что может быть не так... Поскольку это открытый исходный код, я просто взял бы код, вставил его в ваше решение и построил его, чтобы выяснить, что Метод выполнения жалуется. Я обнаружил, что исходный код Fluent Migrator довольно хорошо организован.

Одна вещь, о которой вам, возможно, придется беспокоиться, если это веб-приложение, — убедиться, что никто не использует базу данных во время миграции. Я использовал стратегию установления соединения, установки базы данных в однопользовательский режим, запуска миграций, установки базы данных в многопользовательский режим, а затем закрытия соединения. Это также обрабатывает сценарий веб-приложения с балансировкой нагрузки на нескольких серверах, поэтому 2 сервера не пытаются выполнять миграции для одной и той же базы данных.