I have a project where we use screen DTO\'s to encapsulate the data between the Service Layer and the Presentation Layer. In our case, the pres
Are you using actual services (web or WCF)? If so, then define the DTOs in the service layer and the proxy created when you add a service (or web if using old ASMX) reference will contain all of the DTO types. This is the simplest way to do it and maintains only loose coupling between your ASP.NET project and your service project -- no direct project reference is required in either direction. As you update your DTOs, all you need to do is update your service reference and it will automatically expose the updates to your web project via the proxy class that is generated.
In any event, if you're following something like a DDD approach it is best to have your infrastructure projects (such as a web-platform-specific UI) referencing your domain objects than vice versa. If you follow my advice above, however, your web project won't have a direct dependency on the project at all, which is a good thing, and certainly better than having your rich domain objects depending on your web project (if that were even a consideration - I realize you weren't saying you were doing this).
If your DTOs are view-specific, then I would include them in your UI project. It should really be the controller's job to ensure that the View only gets from the Model what it needs - in your case a value-object with just the fields needed by the view.