DAL -> BLL <- GUI + composition root. How to setup DI-bindings?

Split up the ASP.NET MVC application in two:

• One part is your original ASP.NET MVC application, but without any logic whatsover. Just keep the Composition Root and your Views (.aspx, etc.) in this project. Since this is the Composition Root, you can have references to all your other projects. However, since all logic would have been extracted, this is now a Humble Object, so it's okay to have all the references at this level.
• Extract all the logic (Controllers, etc.) into an Application Model project, which would just be a normal library project (.dll) that references the ASP.NET MVC binaries. This project would need to reference the BLL to get at the interfaces, but that's okay. However, both the Application Model and the BLL are effectively shielded from the DAL.

The resulting layering would look like this:

• ASP.NET MVC application
• Application Model
• BLL
• DAL

Mark Seemann's answer gave me the idea for this variant:

DAL with Repositories -> BLL with services and IRepository <- Asp.net mvc-app
^------------------------^--------- Composition Root <-------´

This is meant to illustrate that instead of letting the Web project reference the DAL it references a separate Composition Root-project that references both DAL and BLL. The composition-root-project has a single class with one method that define the bindings. It gives these additional benefits:

• Only three layers. Four layers would be a tough sell in the team.
• Loose coupling is ensured. It is not possible to access the DAL from view-code.
• Better tool support. Controllers remain at the standard location so "Add Controller" is accessible on the context-menu and missing views are highlighted in the controller-code. Also there is no need to configure or write a custom controller factory.

I don't see any big drawbacks.

Just go with Option 1.

Just because you have a reference to the assembly doesn't mean your breaking the SoC.

The Web Project still knows nothing about the underlying implementations, only the interface.

The Web Project is the "aggregator" of the below layers therefore it makes sense it should know about them in order to configure them.