Configuration services without reference Infrastructure in mvc core

Question

When using Clean Architecture in Mvc Core, Layer with Name can be like this:

1. Infrastructure
2. Core
3. Web

This link has complete description about that:

https://learn.microsoft.com/en-us/dotnet/standard/modern-web-apps-azure-architecture/common-web-application-architectures

Principles says that Web project shouldn't have any reference from Infrastructure class library. So how can use a DI container to resolve the problem?

This code in Startup.cs uses Infrastructure to config some things:

public void ConfigureProductionServices(IServiceCollection services)
{
    services.AddDbContext<CatalogContext>(c =>
    {
        try
        {
            c.UseSqlServer(Configuration.GetConnectionString("CatalogConnection"));
        }
        catch (Exception ex)
        {
            var message = ex.Message;
        }
    });

    services.AddDbContext<AppIdentityDbContext>(options =>
        options.UseSqlServer(Configuration.GetConnectionString("CatalogConnection")));

    ConfigureServices(services);
}

public void ConfigureServices(IServiceCollection services)
{
    services.AddIdentity<ApplicationUser, IdentityRole>()
        .AddEntityFrameworkStores<AppIdentityDbContext>()
        .AddDefaultTokenProviders();

    services.AddScoped(typeof(IRepository<>), typeof(EfRepository<>));
    .
    .
    _services = services;
}

Answer 1

You say:

Principles says that Web project shouldn't have any reference from Infrastructure class library. So how can use a DI container to resolve the problem?

But the article you linked says:

Note that the solid arrows represent compile-time dependencies, while the dashed arrow represents a runtime-only dependency. Using the clean architecture, the UI layer works with interfaces defined in the Application Core at compile time, and ideally should not have any knowledge of the implementation types defined in the Infrastructure layer. At runtime, however, these implementation types will be required for the app to execute, so they will need to be present and wired up to the Application Core interfaces via dependency injection.

What the article is describing is the logical architecture of the application as opposed to the physical architecture of the application. Logically, the user interface knows nothing about the Infrastructure layer, but physically it is the DI code at application startup in the User Interface layer (right at the very beginning of the application at runtime) that composes the application components together. This concept can be illustrated and explained best here.

The idea is that we can use assemblies independently of one another without dragging along additional dependencies. In practice makes unit and integration testing easier and more reliable to do.