Impossibile accedere a un oggetto disposto in ASP.NET Core durante l'iniezione di DbContext

Aggiornamento per ASP.NET Core 2.1

In ASP.NET Core 2.1 i metodi sono leggermente cambiati. Il metodo generale è simile al 2.0, solo il nome del metodo e i tipi restituiti sono stati modificati.

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

public static IWebHostBuilder CreateWebHostBuilder(string[] args)
{
    return new WebHostBuilder()
        ...; // Do not call .Build() here
}

Vale per ASP.NET Core 2.0

Con ASP.NET Core 2.0 sono state apportate alcune modifiche al modo in cui gli strumenti EF Core ( dotnet ef migrations ecc.) Determinano DbContext e la stringa di connessione in fase di progettazione.

La risposta di seguito indica che le migrazioni e il seeding vengono applicati quando si chiama uno qualsiasi dei comandi dotnet ef xxx .

Il nuovo modello per ottenere un'istanza in fase di progettazione per gli strumenti EF Core è l'utilizzo di un metodo statico BuildHostWeb .

Secondo questo annuncio , EF Core utilizzerà ora il metodo statico BuildWebHost che configura l'intera applicazione, ma non la esegue.

  public class Program
  {
      public static void Main(string[] args)
      {
          var host = BuildWebHost(args);

          host.Run();
      }

      // Tools will use this to get application services
      public static IWebHost BuildWebHost(string[] args) =>
          new WebHostBuilder()
              .UseKestrel()
              .UseContentRoot(Directory.GetCurrentDirectory())
              .UseIISIntegration()
              .UseStartup<Startup>()
              .Build();
  }

Sostituiscilo nel tuo vecchio metodo Main

public static void Main(string[] args)
{
    var host = BuildWebHost(args)
        .Seed();

    host.Run();
}

Dove Seed è un metodo di estensione:

public static IWebHost Seed(this IWebHost webhost)
{
    using (var scope = webhost.Services.GetService<IServiceScopeFactory>().CreateScope())
    {
        // alternatively resolve UserManager instead and pass that if only think you want to seed are the users     
        using (var dbContext = scope.ServiceProvider.GetRequiredService<ApplicationDbContext>()) 
        {
            SeedData.SeedAsync(dbContext).GetAwaiter().GetResult();
        }
    }
}

public static class SeedData
{
    public static async Task SeedAsync(ApplicationDbContext dbContext)
    {
        dbContext.Users.Add(new User { Id = 1, Username = "admin", PasswordHash = ... });
    }
}

Vecchia risposta, vale ancora per ASP.NET Core 1.x

Esiste un modello semi-ufficiale su come eseguire il seeding di Entity Framework Core nell'applicazione ASP.NET Core che dovresti applicare, perché all'avvio dell'applicazione non c'è richiesta e quindi nessun RequestServices (che risolve i servizi con ambito).

In sostanza si riduce a creare un nuovo ambito, risolvere i tipi necessari e smaltire nuovamente l'ambito al termine.

// serviceProvider is app.ApplicationServices from Configure(IApplicationBuilder app) method
using (var serviceScope = serviceProvider.GetRequiredService<IServiceScopeFactory>().CreateScope())
{
    var db = serviceScope.ServiceProvider.GetService<AppDbContext>();

    if (await db.Database.EnsureCreatedAsync())
    {
        await SeedDatabase(db);
    }
}

Uno dei motivi per la risoluzione diretta di un servizio tramite app.ApplicationServices.GetService<MyService>() è che ApplicationServices è il provider dell'ambito dell'applicazione (o del ciclo di vita) e i servizi risolti qui rimangono attivi fino allo spegnimento dell'applicazione.

Di solito il contenitore con ambito si risolverà dal suo contenitore padre, se l'oggetto esiste già lì. Pertanto, se si crea un'istanza di DbContext in questo modo nell'applicazione, sarà disponibile nel contenitore ApplicationServices e quando si verifica una richiesta, verrà creato un contenitore figlio.

Ora quando si risolve DbContext non verrà risolto come ambito, poiché esiste già nel contenitore padre, quindi verrà restituita l'istanza del contenitore padre. Ma poiché è stato eliminato durante la semina, non sarà accessibile.

Un contenitore di ambito non è altro che un contenitore singleton con durata limitata.

Quindi non risolvere mai i servizi con ambito nell'avvio dell'applicazione senza utilizzare il modello sopra di prima creare un ambito e risolverlo da esso.