There's been a lot of talk about ASP.NET 2.0's model of project-less web sites (including from Jeffrey Palermo on the latest DotNetRocks show), and whether that's a good thing or a bad thing. The consensus seems to be that it's bad.

I'm still not sure. I haven't dug in enough, but I can think of some pitfalls already. How do you manage references and know to re-copy them if they've been updated? How can you exclude a file from a web site without deleting it? With a project file this is easy.

On the other hand, how many times has the project file come back to bite you? And I don't just mean two people needing access to it at the same time - that's an easy one. I'm talking about virtual folders and the pitfalls of dealing with those, editing project files by hand, getting a new developer the latest version, things like that. I've gotten intimately involved in the details of the csproj file, the .sln file and .csproj.webinfo files. Not something I should have to do, in my opinion.

So what's the best method? I have no idea. The pitfalls are potentially big to me, but the benefits are enticing too. Being able to open any folder as a web folder sounds pretty nice, but in practice, will it be used? If no project file is needed for web apps, why then do we need it for other project types? They still have them, right? Couldn't most of the problems have been solved by just removing the IIS binding information from the solution and projects, and using the "Cassini-esque" web server built in? That way, managing what files are included, references, where code is, etc. would all be easy. You could also then provide a way to handle compilation easier - yeah, the compile into 100s of DLLs may be useful for debugging (pseudo edit-and-continue!), but in release mode, you don't need this.

I'm sure this is too simplistic, and I haven't played as much as I should have, but to me, it sounds like we've gone from one extreme to another. Maybe in the next iteration, we'll settle somewhere in the middle.