How to make the data access technology (Entity Framework) ignorance from the presentation layer (ASP.NET MVC)?

Premise:

I am exercising Domain-Driven Design and I separate my solution into 4 layers:

• Presentation Layer
  • An ASP.NET Web API 2 project for a RESTful API web service
  • An ASP.NET Web MVC5 project for a documentation and admin screens
• Application Layer
  • A class library project responsible to take commands from presentation layer and consume any domain services
• Domain Layer
  • A class library project that contains business models and logic
  • A class library project that contains the domain services
• Infrastructure Layer
  • A class library project that contains all the concrete implementation, like dataq persistance using Entity Framework, logging using Log4net, IoC using Simple Injector, etc

The domain layer only has a set of repository interfaces defined for the aggregates and it's up to the implementation data access mechanism which exists in the infrastructure layer to hide the implementation details.

In this exercise, I decide to use Entity Framework Database first approach. And of course, there is a app.config in the infrastructure project that contains a connection string.

Problems:

Ok, I spend a great deal and time trying to separate all the concerns and to focus on domain models. In the presentation layer (i.e., the API and MVC projects), there is no direct reference to the infrastructure project. And IoC container has been setup so all concrete implementation of the required interfaces would be injected into controller constructors.

When I select, for example, the API project as start project and run it, I got

An exception of type 'System.InvalidOperationException' occurred in EntityFramework.dll but was not handled in user code.

Additional information: No connection string named 'xxxxxx' could be found in the application config file.

Question:

Now I understand if I install Entity Framework into the API project, copy and paste connection string from the app.config of the infrastructure project into the web.config of the API project, things will work. But that breaks our original purpose of separating concerns, doesn't it? If we do that, then what's the point of using Domain-Driven Design and making the data access technology ignorance from the presentation layer?

The reason we don't directly reference direct implementation of data access technology (i.e. concrete implementations that use dbContext and Linq) is that we could easily switch the underground access technology to something else.

So what would be the proper way to do it?!!

I do not want to install Entity Framework in my presentation layer, nor copy the connection string everywhere. I want all the data access and concrete implementation of repositories exist in just one library.