Startup class ConfigureServices method not called during migration

[matthieugd]

I have a class library project migrated from beta 3 to beta 4. In beta 3 I was able to call

k ef migration add <migration name> -c <dbcontextname>

from a command line as I provide a Startup class in my class Library project with a ConfigureServices method which configure the dbcontext .

With beta 4 I got this exception:
System.InvalidOperationException: No data stores are configured. Configure a data store by overriding OnConfiguring in your DbContext class or in the AddDbContext method when setting up services.

I look at the code source for ContextTool class but it's not very clear how the Startup class is used or why it would fail.

Any idea ?

[matthieugd]

But it's not supposed to use the startup class first? If you look at the CreateContext method there's a first attempt to create from startup and then use the default ctor.

Why the startup class is not called ?

Le 2015-05-26 à 20:23, MaximBalaganskiy notifications@github.com a écrit :

Seems like Startup class is not used for migrations. The error you get indicates that your context does not have a connection string. Try setting it like this

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
base.OnConfiguring(optionsBuilder);
optionsBuilder.UseSqlServer("connectionString");
}
and your migrations will work.

—
Reply to this email directly or view it on GitHub.

[MaximBalaganskiy]

My fault. It is called...

[MaximBalaganskiy]

I've just put an exception into a startup and migration started failing for me in a fresh MVC project

[MaximBalaganskiy]

So after experimenting with it a bit I've found that Startup is called when migration is called on the original MVC project and ignored when migration is called on a class library.

[matthieugd]

Did you try in a class library project? I defined an ef command and run it with the arguments (i.e. migration add -c )

It seems that it's supported by looking at the TryCreateContextFromStartup method but the try/catch is hiding the problem since the default actor of my DbContext is called and my Startup class is not.

https://github.com/aspnet/EntityFramework/blob/7.0.0-beta4/src/EntityFramework.Commands/ContextTool.cs#L47

[MaximBalaganskiy]

Yep, looking at the code seems like it should work...

[matthieugd]

It seems that something is failing during the initialization of the hosting service and context. I'm going to look into it tomorrow.

Le 2015-05-26 à 21:46, MaximBalaganskiy notifications@github.com a écrit :

Yep, looking at the code seems like it should work...

—
Reply to this email directly or view it on GitHub.

[MaximBalaganskiy]

Alright. I managed to make it work by creating a class library out of an MVC project and stripping almost everything from it. There is another problem though with migrations. They don't work consistently. I'm always able to create the first migration. But the second or third one is basically a matter of luck.

Removing the code to apply migrations from the default constructor helps a lot - migration creation becomes stable.

[divega]

Startup is called when migration is called on the original MVC project and ignored when migration is called on a class library.

That is correct, and actually by design: on an ASP.NET application Migrations will use the application's startup code to get the the application's service container setup the same way it would get setup at runtime. A class library shouldn't need to have its own startup code or service container, unless it isn't really a class library but something else, e.g. a test suite or a command line app.

It would really be good for us to understand how and why you ended up wanting to get things working in this way.

[MaximBalaganskiy]

I moved the ApplicationDbContext to a separate project and added more project specific tables to it.
As I understood, I cannot currently create migrations for referenced assemblies. So the only option is to create migrations from the DataAccess assembly itself. But without the Startup working you cannot nicely pass a connection string to the context. Hope that clears my case :)

[matthieugd]

It's a command line app use to create and apply migrations. It was working with beta 3 and it was very handy.

What's the purpose of commands if we need an ASP.NET application to use them ?!?

Le 2015-05-27 à 00:47, Diego Vega notifications@github.com a écrit :

Startup is called when migration is called on the original MVC project and ignored when migration is called on a class library.

That is correct, and actually by design: on an ASP.NET application Migrations will use the application's startup code to get the the application's service container setup the same way it would get setup at runtime. A class library shouldn't need to have its own startup code or service container, unless it isn't really a class library but something else, e.g. a test suite or a command line app.

It would really be good for us to understand how and why you ended up wanting to get this the work in this way.

—
Reply to this email directly or view it on GitHub.

[MaximBalaganskiy]

@matthieugd Until #2256 is resolved I will be putting my DbContext in stripped MVC project. Works just fine.

[matthieugd]

That's what I'm going to do. Thanks @MaximBalaganskiy

[matthieugd]

@MaximBalaganskiy : what did you keep in your MVC stripped project? Can you share a screenshot of the solution explorer?

[MaximBalaganskiy]

Will do tomorrow - the project is at work.
I think it's something in project.json. I remember even deleting wwwroot didn't brake it.