1

I asked a question a while back about seamless updates:

Seamless EF Migrations from Staging > Production with Schema Change

I think a simple way to achieve this is to simply suppress the error The model backing the 'ApplicationDbContext' context has changed - this way I can

  1. Publish my app to a staging slot
  2. Test migration against a staging db
  3. Swap staging/production
  4. Migrate directly to Prod

This is what I do now, but between 3 and 4, there are a few seconds where the dbContext throws that error. If I could simply suppress that error... we could eliminate 95% of those errors across those few seconds (the 5% being errors that we catch resulting from the drifted model).

Is there a way to suppress this error but keep migrations enabled?

Update:

Using the link here I was able to test out the following:

    public ApplicationContext()
        : base("name=DefaultConnection") {
        this.Database.Log = s => System.Diagnostics.Debug.WriteLine(s);
        Database.SetInitializer(new SuppressedInitializer<ApplicationContext>());
    }


public class SuppressedInitializer<TContext> : IDatabaseInitializer<TContext>
where TContext : DbContext {
    public void InitializeDatabase(TContext context) {
        if (!context.Database.Exists()) {
            throw new ConfigurationException(
              "Database does not exist");
        }
        else {
            if (!context.Database.CompatibleWithModel(true)) {
                var contextException = new InvalidOperationException("The database is not compatible with the entity model.");
                Elmah.ErrorSignal.FromCurrentContext().Raise(contextException);
                // intentionally don't throw so that the application may continue
            }
        }
    }
}

contextException is created when I expect it to and I believe this is a solution.

Community
  • 1
  • 1
RobVious
  • 12,685
  • 25
  • 99
  • 181
  • This may help. Basically you can test if the model is compatible and take whatever action you require. https://coding.abel.nu/2012/03/prevent-ef-migrations-from-creating-or-changing-the-database/ – Steve Greene Aug 09 '16 at 14:45
  • @SteveGreene interesting - is this approach compatible with the current version of EF? – RobVious Aug 09 '16 at 15:48
  • Works in EF 6. Not sure about core. – Steve Greene Aug 09 '16 at 17:53
  • @SteveGreene - just tried it out and it's not working. Dug around and found this: http://stackoverflow.com/questions/9703810/how-to-disable-migration-in-entity-framework-4-3-1 – RobVious Aug 09 '16 at 18:01
  • What's not working? I have it in multiple PROD apps. You do need to check before you initialize the context. I have mine in the STATIC constructor. – Steve Greene Aug 09 '16 at 18:09
  • @SteveGreene - `SetInitializer` was unavailable from my context. Placing it in the constructor works - but then `TransactionScope` throws errors around constructor arguments (should be initialized with 0, 1 is provided). Removing the `using` gets everything compiling... but then suppression doesn't work. Adding code into my question with details. – RobVious Aug 09 '16 at 18:28
  • @SteveGreene - the exception thrown was actually from my tweaked model, so I believe this works. One concern I have is around `TransactionScope` being removed - is that essential? Either way - feel free to add this all in an answer of your own so I can accept and get you some more rep for this :) – RobVious Aug 09 '16 at 18:32
  • Static constructor (not the regular constructor), right? – Steve Greene Aug 09 '16 at 19:13
  • @SteveGreene actually - the regular one. Updating my question with details. – RobVious Aug 09 '16 at 19:30
  • I prefer static: http://stackoverflow.com/questions/16727585/database-setinitializer-to-null-not-working-entity-framework-4-3-1-code-first#16727643 – Steve Greene Aug 09 '16 at 20:05

0 Answers0