In hierarchical order:

$App.Utility (reference nothing)
\Math (Utility functions)
\IO (Utility functions)
\Graphic (Utility functions)
\Xml (Utility functions)

$App.Commons (reference only $App.Utility)
\Entity (domain)
\Contract (domain)
Constants.cs (enums, etc.)

$App.Web (reference only $App.Commons Controls Utility Presenters)
\Api (usually REST/ASMX based API gateway talking ONLY to Presenters)
\Language (XML based localization files that cross app boundaries [no .RESX])

$App.Web.Widgets (reference nothing)
\Controls (Server Controls)

$App.Presenters (reference anything, except $App.Data Web)
\Presenter (domain aware, calls $App.Business)
\Helpers (domain aware, UI technology aware)
ResourceHelper.cs

$App.Business (reference anything, except $App.Presenters Web)
\xxx-Manager (domain aware, calls $App.Data)
\yyy-Manager (domain aware, calls $App.Data)
\zzz-Manager (domain aware, calls $App.Data)

$App.Data (reference only $App.Commmons)
\Repository (persistence)
\SQL (create DATABASE objects)

Notes:

1. $App.Utility & $App.Commons can be used, referenced anywhere, and will typically cross application boundaries (e.g. travel through API, get used by “add-on” products).
2. $App.Presenters is the linch-pin: all API calls and web UI go through this (single version of the truth?).
3. $App.Commons never carries any “excess baggage” to ensure that Entity classes (Value Objects) are not decorated with technology/framework specific Attributes.
4. Localization is a first-class citizen across the entire application stack, AND needs to be accessible by “add-on” or third-party applications.

This is very helpful when your developing applications with multiple UIs, for example I have web applications that are public facing on one set of web servers, have a web service interface on another set of servers, and an internal admin on another set of servers. Next I have multiple applications that use the same data but in different ways, so by breaking the DAL into it’s own project I get away from having a huge BIZ that’s everything to everyone. Honestly, are multiple assemblies really that hard to deal with? Plus by breaking it into multiple Assemblies means you can reuse your assemblies as libs in more then one applications, and not just coping and pasting the code.

My preference is to have 4 projects (UI, BIZ, DAL, OBJECTS(entities, interfaces, etc.)) and then test projects for each one. This way it forces good design, and gives me the flexibility to expand the application easily, I’ve been bitten too may times by the this functionality will only be used by this application, 2 projects later, needing to include the same functionality.