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 [email protected] 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 [email protected] 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 [email protected] 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.

[matthieugd]

I added the wwroot and the "webroot": "wwwroot" in the project.json, no luck :( I'm going to start from a empty mvc project ...

[MaximBalaganskiy]

I just did the same. Deleted everything. The only difference from the class library was

<DevelopmentServerPort>1147</DevelopmentServerPort> 

tag in the xproj file.

Then I tried creating a class library and putting that tag in - worked as well, although had to reboot VS :)

Looks like black magic to me.

[matthieugd]

I think I found it: the Startup class must have the Configure(IApplicationBuilder app) method, it's checked in one of the EnsureXXXX methods of the Hosting class.

I added it in my class in my Library project and it works.

[MaximBalaganskiy]

I had this method all along and it did not work for me but now it does. This is confusing.

[bricelam]

The original issue sounds like a duplicate of #2219.

Removing the code to apply migrations from the default constructor helps a lot

Yes, the constructor code is an awful workaround that I've been hoping they'd remove for a few releases now.

I cannot currently create migrations for referenced assemblies.

You should always invoke the commands on the assembly that you want the migrations to live in. If you want this to be a different assembly than the one containing your DbContext, scaffold the first migration in the same assembly as your DbContext then move it into the desired project. You should then be able to add additional migrations to the new project.

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

We have plans to create a standalone command-line interface. (See #646) Applying migrations will also be part of deploying an ASP.NET application.

The Startup class must have the Configure(IApplicationBuilder app) method, it's checked in one of the EnsureXXXX methods of the Hosting class.

You should file a bug on Hosting. The method clearly isn't used for design-time scenarios.

[rowanmiller]

Closing as we think we have everything from this thread already captured in other issues (see post above from @bricelam). Feel free to reopen if there is something we missed.