On my current project, we had the majority of our ASP.NET 1.1 to 2.0 conversion completed by the time the Web Application Project add-in came out. We made a short attempt to convert our solution back, but we had already made a number of architecture decisions based on the new web site project type. We've had a number of issues with references and ambiguous errors when we choose "Rebuild web site", so we've been doing a Rebuild Solution every time and it has gradually just gotten worse and worse in performance when "building" the web site. If you are getting ready to do a large web application conversion, by all means just start off using the Web Application Project. It will ship as part of VS Service Pack 1, but you can download it separately (fully supported) now. This works much like VS 2003 and integrates better with source control, deployment is more intuitive, etc. You do miss out on a few of the nice features of the new web site "project-less" model though.
After a lot of frustration, we finally set up a meeting with Microsoft to figure out what we could do differently and if we were missing anything. Turns out there are a couple simple things to keep in mind that make this process a whole lot less hassle. Here is something to keep in mind with the new web site and compilation model in ASP.NET 2.0 and VS 2005. There is NO output from the web site if you choose to build it. Everything happens when an HttpRequest is made for the page. In fact, this is what Visual Studio is doing during design time. When you open an aspx codefile in VS, that page is basically requested from the ASP.NET hosting process running inside VS 2005. This is how you get errors in your task list, partly how Intellisense works and why sometimes when you load the page class file you initially get a bunch of "squigglies" indicating errors until the background threads confirm all the references still work.
In the early betas, there was no Build Web Site command at all, only a Validate Web command. The functionality of this command never changed, just the naming because early feedback indicated developers had no idea how to work with a web site they couldn't "build". I remember wondering this myself. So really when you bulld a web site, in effect you are really saying "Go out and validate that I will be able to compile when I decide to run this page in a web browser". Which of course takes just as much time as an actual binary build because all the references have to be checked and a test "precompile" done on every page, control and class.
Here's the trick (or really just how to properly configure your project) to get around this behavior. Open the properties window of your web site (right-click) and go to the Build tab. If you typically run your web site when developing by using F5, set your Start Action (F5) to "No Build". Also, uncheck the box that says "Build web site as part of solution". Now if you do a Rebuild Solution, all you are doing is building whatever other assemblies you have in your solution and copying those outputs, as well as any dlls you have referenced using file references to the \bin directory. Dropped the time it takes our project to do a Rebuild Solution from 2-4 minutes down to 10 seconds. Nice.
Here's what you lose. You won't get a list of all the errors that currently exist in your web site. So you won't know there is an error on the page unless you have it open in Visual Studio or you try to run the page in a browser and it fails to compile at runtime. For me, this is a reasonable tradeoff during development. You will still need to "build" the web site if you are using the Web Deployment Project, but you can do this only in your "Release" configuration where you actually want to output the site for deployment.
Kristin and I raced up the Oregon coast to get to Cannon Beach for the sunset. It was rather otherworldly with the mist and pink light. Check out my Flickr photos for more.