Discussion for announcement: EF Core 2.0: design-time DbContext discovery changes

[divega]

This is the discussion thread for aspnet/Announcements#258.

[thiennn]

In 2.0 Preview 1. I implemented IDbContextFactory because I don't want Add-Migration, Update-Database,... to run my Startup.cs. It worked as expected.

In Preview 2, I changed to IDesignTimeDbContextFactory, but when I run Add-Migration, I see it run both ConfigureServices and Configure in Startup.cs before CreateDbContext of IDesignTimeDbContextFactory. Is this a expected new behavior?

[divega]

In Preview 2, I changed to IDesignTimeDbContextFactory, but when I run Add-Migration, I see it run both ConfigureServices and Configure in Startup.cs before CreateDbContext of IDesignTimeDbContextFactory. Is this a expected new behavior?

I suspect we changed the order in which things are discovered. I can't recall if we made an explicit decision that this was ok. @bricelam?

[bricelam]

Nothing has changed. As part of discovering DbContext types, we have always tried to construct the application service provider. IDesignTimeDbContextFactory is only a hook for overriding the construction of DbContext types (not the discovery).

[ajcvickers]

@bricelam Do we need the service provider to discover context types?

[bricelam]

We always look in three places:

1. Referenced by IDesignTimeDbContextFactory implementations in the assembly or startup assembly
2. Registered in the application's service provider
3. DbContext derived types in the assembly or startup assembly

After we've discovered them all, we pick one to use.

I've considered having a way to bypass the type discovery (e.g. specify an assembly-qualified name on the command) and then discover a construction mechanism (factory first, service provider second, default constructor last), but this would require a completely separate (new) code path, and the value always seemed minimal.

[bricelam]

We could also look into ways of short-circuiting the type discovery so Startup isn't run if we find the specified type from its factory. (note, not specifying -Context would still need to look in the service provider to ensure there's still only one)

[ajcvickers]

@bricelam I think it's very useful to have an escape hatch that doesn't involve trying to build the application's service provider since doing so could have side effects that need to be avoided. I had assumed that having a factory was the way to do that. Maybe the short circuiting would be the way to enable this.

Moving temporarily out of Discussions so we can triage this.

[thiennn]

I hadn't deep dived into the internal implementation of the type discovery. But I have code for both 2.0 preview 1 work as expected https://github.com/simplcommerce/SimplCommerce/tree/master and 2.0 preview 2 not work as expected https://github.com/simplcommerce/SimplCommerce/tree/netcore2preview2

[ajcvickers]

@thiennn When you say, "not work as expected" can you be more specific? Does it throw an exception? If so, what is the exception message and stack trace? If it doesn't throw an exception, then other than it running code when you don't expect it to, what is not working?

[thiennn]

@ajcvickers like my earlier comment. In 2.0 preview1: Add-Migration, Update-Database command doesn't invoke Startup.cs. But in 2.0 preview 2, it run both ConfigureServices and Configure of Startup.cs

[ajcvickers]

@thiennn Yes, but then what happens? Does the command complete successfully? Do you get an error?