Added default constructor for CoreDbContext to allow Code First Migrations

[promontis]

#5

After this change, I can succesfully create a code first migration configuration class. From this I can update my database using automatic migrations or, if needed, add code migrations.

You might want to change the default connectionstring. I choose this one, but feel free to change it if you feel like it.

[brockallen]

Thx -- will take a look when I can.

[promontis]

I've added a commit to fix an error I had which is caused by proxy classes for EF. AutoMapper seems to have a problem detecting the correct entity type (it sees the proxy class type) and throws.

[brockallen]

BTW, which connection string should be used with a default ctor? I had the same issues with MembershipReboot.

[promontis]

I've named the connection string with the default ctor "Thinktecture.IdentityServer.Core", but this can be anything you like. From what I've seen, most libraries tend to use the same name as the project for the connection string.

[brockallen]

BTW, we now have 3 DbContext-derived classes. Any changes to your thinking?

[promontis]

No, not really. I think it makes things easier, so good refactoring!

However, I do wonder whether it is possible to ship the Migration Configuration within the library. Currently, I've created the Configuration classes (now updated to target all three of the contexts), but it should be possible to add this code to the library. Will investigate if possible and what other libraries are doing.

[promontis]

Regardless whether the Configuration classes should be put in the library, I think it would be best if all the contexts have a default constructor (which implies the use of a default connection string).

Could you add those so that we can run code migrations?

For example, this is what I am doing now:

internal sealed class ConfigurationDbContextConfiguration : DbMigrationsConfiguration<Thinktecture.IdentityServer.Core.EntityFramework.ConfigurationDbContext>
    {
        public ConfigurationDbContextConfiguration()
        {
            AutomaticMigrationsEnabled = true;
        }

        protected override void Seed(Thinktecture.IdentityServer.Core.EntityFramework.ConfigurationDbContext context)
        {
            //  This method will be called after migrating to the latest version.

            //  You can use the DbSet<T>.AddOrUpdate() helper extension method 
            //  to avoid creating duplicate seed data. E.g.
            //
            //    context.People.AddOrUpdate(
            //      p => p.FullName,
            //      new Person { FullName = "Andrew Peters" },
            //      new Person { FullName = "Brice Lambson" },
            //      new Person { FullName = "Rowan Miller" }
            //    );
            //
        }
    }

and then from the package console
update-database -script -ConfigurationTypeName ConfigurationDbContextConfiguration

Currently, this doesn't work anymore because of the following error: The target context 'Thinktecture.IdentityServer.Core.EntityFramework.ConfigurationDbContext' is not constructible. Add a default constructor or provide an implementation of IDbContextFactory.

When I pulled the sources, added the ctors myself, everything works wonderfully! :)

[promontis]

Oh, and if you agree with the changes, could you also push the changes to nuget (or myget)? Would make me very happy 👍

[promontis]

The Configuration classes cannot be added to this project; it is not supported. See: https://entityframework.codeplex.com/workitem/2440

You have to add the Configuration classes to your own project, by executing

Enable-Migrations -ContextTypeName Thinktecture.IdentityServer.Core.EntityFramework.ClientConfigurationDbContext -ContextAssemblyName Thinktecture.IdentityServer.Core.EntityFramework

EF6 will then add the configuration class to your project. Copy and rename it two more times for the other dbcontexts in this project.

Furthermore, one should specify MigrationsNamespace for each context in order to distinctly identity which migration belongs to which context

    internal sealed class ScopeConfigurationDbContextConfiguration : DbMigrationsConfiguration<Thinktecture.IdentityServer.Core.EntityFramework.ScopeConfigurationDbContext>
    {
        public ScopeConfigurationDbContextConfiguration()
        {
            AutomaticMigrationsEnabled = false;
            MigrationsNamespace = "Shoegle.Auth.Migrations.ScopeConfiguration";
        }

        protected override void Seed(Thinktecture.IdentityServer.Core.EntityFramework.ScopeConfigurationDbContext context)
        {
        }
    }

After doing this you can either use automatic-migrations (not recommended) or generate code first migrations classes. As stated in the work item, this will change in EF7.

[brockallen]

Quick update -- I added default ctors to the DbContext classes. I'm now thinking about how to approach migrations. Any updates to your thinking?

[brockallen]

I manually added this on the dev branch. Can you check to see if it allows you to do what you need?

[promontis]

It's awesome! Thnx 👍