0
votes

I would like to ask on why the >dotnet ef migrations add InitialMigration

behaves differently on these 2 program.cs code

Code 1:

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

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

Code 2

public static void Main(string[] args)
    {
         CreateWebHostBuilder(args).Build().Run();
    }

    public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
        WebHost.CreateDefaultBuilder(args)
            .UseStartup<Startup>();

With Code-1, I am able to run >dotnet ef migrations add InitialMigration without an error. Using the PackageManager Console> add-migration Initial Migration No Error as well.

But with Code-2, I am having an Error on both Pakckage Manager Console and command prompt. Here is the error:

Unable to create an object of type 'AppDbContext'. Add an implementation of 'IDesignTimeDbContextFactory' to the project, or see https://go.microsoft.com/fwlink/?linkid=851728 for additional patterns supported at design time.

As I understand it, both codes basically doing the same thing.

1
I just got new information: I think that the add-migation or the dotnet ef migrations command calls the BuildWebHost method in the program.cs file. So when I change the method name in Code-2, this is the error I got: PM> Add-Migration initialmigration An error occurred while calling method 'BuildWebHost' on class 'Program'. Continuing without the application service provider. I think, that the migration command needs an IWebHost provided by the build command to workAndy Parinas

1 Answers

0
votes

The convention changed between ASP.NET Core 2.0 and 2.1.

In 2.1, the static method is supposed to return the IWebHostBuilder (for tooling reasons).

However, you will need the version of dotnet ef that ships as part of the 2.1.300 SDKs (only a release candidate is available at the time of writing) instead of the one currently shipping as CLI tool reference (DotNetCliToolReference in the project file).

This was an issue for the SPA templates that were updated in between releases which now follow the new convention but are targeting 2.0 - https://github.com/aspnet/templating/issues/442.

You can easily change your code to be similar to the Code 1 example you provided or update to the RC version of the tooling that is available at the time of writing.