efcore: Cannot make migration. ef core 2.0

@Sweetog look at paragraph dotnet ef database update and there is a comment:

In order for the EF Migrations tooling to work you MUST NAME THE METHOD: BuildWebHost just like the example … you cannot use a different method name.

So you just need to update your Program.cs to:

    public class Program
    {
        public static void Main(string[] args)
        {
            BuildWebHost(args).Run();
        }

        public static IWebHost BuildWebHost(string[] args) =>
            WebHost.CreateDefaultBuilder(args)
                .UseStartup<Startup>()
                .Build();
    }

Changing Program.cs to one quoted in the article fixed the error for me. No IDesignTimeDbContextFactory needed.

Here is my context:

    public class ApplicationDbContext : IdentityDbContext<ApplicationUser, ApplicationRole, string>
    {
        public DbSet<SomeEntity> SomeEntities { get; set; }

        public ApplicationDbContext(DbContextOptions options) : base(options) {}
    }

Scenario 1 - old way of Program.cs

    public class Program
    {
        public static void Main(string[] args)
        {
            IWebHost host = WebHost.CreateDefaultBuilder(args)
                .UseStartup<Startup>()
                .Build();

            host.Run();
        }
    }

…and migration (I use -s because I have all my DB stuff in separate project):

Scenario2 - new way of Project.cs

Just one change here:

    public class Program
    {
        public static void Main(string[] args)
        {
            BuildWebHost(args).Run();
        }

        public static IWebHost BuildWebHost(string[] args) =>
            WebHost.CreateDefaultBuilder(args)
                .UseStartup<Startup>()
                .Build();
    }

…and magic happen:

For me none of the above solutions helped. But then I set my web project as startup and then it worked!

We can create a new class file into our solution and add the following code into it then use add-migration it will definitely work

public class DesignTimeDbContextFactory : IDesignTimeDbContextFactory<AppDbContext>
    {
        public AppDbContext CreateDbContext(string[] args)
        {
            IConfigurationRoot configuration = new ConfigurationBuilder()
                .SetBasePath(Directory.GetCurrentDirectory())
                .AddJsonFile("appsettings.json")
                .Build();
            var builder = new DbContextOptionsBuilder<AppDbContext>();
            var connectionString = configuration.GetConnectionString("MyAppCS");
            builder.UseSqlServer(connectionString);
            return new AppDbContext(builder.Options);
        }
    }

@ajcvickers Hi, thanks the your the link you shared (https://docs.microsoft.com/en-us/aspnet/core/migration/1x-to-2x/). But this article does not give a single example of implementing IDesignTimeDbContectFactory<>

Can we get a convention that behaves similarly, but doesn’t require anything ASP.Net Core specific? I’m writing CLI tools here with no web interface, I don’t want to have to implement an IDesignTimeDbContextFactory when I’m using AddDbContext on a ServiceCollection anyway…

Changing Program.cs to one quoted in the article fixed the error for me. No IDesignTimeDbContextFactory needed.

Here is my context:

    public class ApplicationDbContext : IdentityDbContext<ApplicationUser, ApplicationRole, string>
    {
        public DbSet<SomeEntity> SomeEntities { get; set; }

        public ApplicationDbContext(DbContextOptions options) : base(options) {}
    }

Scenario 1 - old way of Program.cs

    public class Program
    {
        public static void Main(string[] args)
        {
            IWebHost host = WebHost.CreateDefaultBuilder(args)
                .UseStartup<Startup>()
                .Build();

            host.Run();
        }
    }

…and migration (I use -s because I have all my DB stuff in separate project):

Scenario2 - new way of Project.cs

Just one change here:

    public class Program
    {
        public static void Main(string[] args)
        {
            BuildWebHost(args).Run();
        }

        public static IWebHost BuildWebHost(string[] args) =>
            WebHost.CreateDefaultBuilder(args)
                .UseStartup<Startup>()
                .Build();
    }

…and magic happen:

Thank you so much, just change the name of CreateWebHostBuilder solved the problem

Seems this particular issue has a couple of a root causes and we STILL aren’t there yet in working it all out. I will provide another GOTCHA:

If the db doesn’t exist, and you try to dotnet ef migrations add InitialCreate, it’ll fail. You must run a dotnet ef database update first. Got to love those completely misleading error messages.

For the record:

I had the same issue which was driving me crazy. I finally found the root cause (in my case)

my appsettings.json had this setting:

"Logging": { "IncludeScopes": false, "LogLevel": { "Default": "Verbose", "System": "Information", "Microsoft": "Information" } }

Simply changing it by this solved the problem:

"Logging": { "IncludeScopes": false, "LogLevel": { "Default": "Warning" } }

I had scrapped a database, deleted my migrations and tried to start over and started getting this error message.

All I did to get Add-Migration to work again was comment out the seeding method call in Configure() myContext.EnsureSeedDataForContext();

Yes it does actually.

I was able to create the DesignTimeContextFactory. Then I used <PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="2.0.1" /> instead of <DotNetCliToolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="2.0.1" /> which allowed me to run migrations where the project was netstandard2.0 instead of netcoreapp2.0. Thanks.

@crasshacker you do not need to add IDesignTimeDbContextFactory, in your Program.cs you have to have a method named “BuildWebHost”:

        public static void Main(string[] args)
        {
            //you must must have a method/function name "BuildWebHost" otherwise EF Core Migrations will throw an execption that you need to have an implementation of IDesignTimeDbContextFactory
            BuildWebHost(args).Run();
        }

        public static IWebHost BuildWebHost(string[] args) =>
           WebHost.CreateDefaultBuilder(args)
               .UseStartup<Startup>()
               .Build();

@cbmek you are correct! wow and here I wasted so much time implementing IDesignTimeDbContextFactory and I was so bothered that I had to load appsettings again and none of the articles online even gave a thought about environment specific appsettings and all I need was a method named BuildWebHost

This message may surface if you have an error anywhere in your startup process even if everything else is configured correctly. For me, in Startup.cs I was trying to parse a key which didn’t exist in appsettings.json. I forgot that I had renamed it and never tried running the application which probably would have shown me the exception.

In case this helps anyone. I was getting the “Add an implementation of ‘IDesignTimeDbContextFactory<MyDbContext>’” error too. For me it was because I was not adding the DBContext to my service provider. In my case I happened to be changing from using a SQL Server database to a SQLite one. I had accidentally removed the “UseSqlServer” line without adding back a “UseSqlite”. So now I have something like this in “Startup.cs”

public class Startup
{
    public Startup(IConfiguration configuration)
    {
        Configuration = configuration;
    }

    public IConfiguration Configuration { get; }

    public void ConfigureServices(IServiceCollection services)
    {
        services.AddMvc();
        services
            .AddDbContext<MyDBContext>(options => options.UseSqlite("Data Source=myDB.db"));
...

In case this helps anyone. I had the exact same error while creating a new project with an n-Tier design. At some point I had set my data access layer as the default startup project. I found that migrations worked again once I set the startup project to the web project where startup.cs and project.cs resides.

@colotiline It looks like this is fixed in the latest codebase.