As a full time ASP.NET developer, this is one of my favorite Whidbey features: ASP.NET offers support for File System and FTP projects, and much smoother Local IIS integration. That's going to save me tons of time and aggravation.
The DLL location process (probing) used for .NET Windows applications has always pretty durned sophisticated. The ASP.NET method, on the other hand, is pretty simple - go to the app root, look for a sub-folder called bin, and that's where the DLL's must be. I've always wondered why, every time I popped open the IIS MMC.
It's not because it's impossible to determine other likely locations - the web.config can be in any any subdirectory in the path hierarchy. More likely was that (1) there's some kind of security or permission issue I haven't considered, (2) that I'm the only person this bugs, or (3) this was lower priority than other features that have made it to the platform to date. I'd hoped it was the third...
Now, it's not like this is much of a problem when you're creating a new web app - VS.NET creates the a virtual for you. So, what's the problem?
1. Complicates deployments - Web Setup Projects can simplify the process, but the fact is that setting up a new web app means getting on the server - not the XCOPY deployment model .NET uses elsewhere. Desktop app setup got simpler with .NET, and Web app deployment acutally got harder - ASP deployment was just copying files, which were all self contained. This is more painful if you're working on a big team, on lots of ASP.NET apps.
2. Sample code / projects require installation - Desktop / Console apps are simple; ASP.NET apps require several steps: (1) copy to a folder (2) set up a Virtual Root with IIS Application (3) edit the webinfo and sln files to point at your virtual, if you plan to open the solution instead of the project.
ASP.NET projects use the IIS Application as a process boundary, a means of keeping Sessions and Applications separate between Apps, etc. - see Paul Wilson's excellent articles about IIS Applications and ASP.NET Specifics and IIS Applications and Virtual Directories. I wonder how the new Web Projects handle this?
The new Web Projects can run from a file system path (independant of IIS) or FTP location. The local IIS config looks like it ties in better with IIS on site creation - I really hope this integration also improves upon the current “sorry, we can't find the project url even though you just double clicked on it” dialog...