I've been on vacation the last few days in Mexico (and fly back Sunday night), so am just catching up on all the web project system threads that have been flying the last 48 hours (serves me right for finding an internet cafe to check my email when I'm not supposed to).
I'm planning on posting a blog post on Monday or Tuesday when I get back that goes into the web project system in more detail and why we've made some of the changes we've made. My sense in reading some of the recent comments is: 1) we haven't done a good job of explaining all the new capabilities that the new web project system provides (and there are a lot of good new features), and 2) we haven't done a good job of clarrifying people's concerns about the changes and what they might worry about loosing in terms of functionality as a result of them.
One thing I wanted to clarrify before my uber-post about the web project system is that the Beta2 release was a beta -- and one where the code was frozen way back in February (this is when teams forked to work on the RC code-branch). A lot of changes and improvements have occured since then (thanks in large part to feedback from the community), and most (if not maybe all that I've seen recently) of the "missing functionality" that has been called out as part of these discussions is now fully supported in post-beta2 builds.
Specifically, the 5 "functionality is missing" concerns I've seen called out that I want to clarrify and hopefully allay people's concerns before my more detailed post next week:
Concern #1: Source control checks in binaries in the \bin directory.
Update: Just to clarrify -- this behavior was never by design (since it makes source control extremely painful to use), but was rather a late-regression in the beta2 tree that wasn't caught in time to fix before beta2 was released. This has been fixed since then and will not occur in the final product.
Concern #2: Lack of exclude file support.
Update: This was something we origionally thought wasn't needed because of a new feature in web compilation that allows projects to skip and continue over compile errors (a very useful feature actually when working on large projects with lots of pages where you don't want to constantly exclude pages that are temporarily broken -- a new feature not supported in VS 2003). The feedback after beta2 clearly indicated we were wrong so we added it back in and it has been in builds for a few months. It will be supported in the final product.
Concern #3: Web projects don't support file-based assembly references (the Copy-Local flag feature in VS 2003).
Update: This was a missing feature in Beta2 that we've also added support for and is in recent builds, and will be supported in the final product.
Concern #4: In Beta2 a separate assembly was created for each page when using the "Publish Web" wizard in VS.
Update: The web project system supports a granular level of assembly creation. In Beta2 it supported lots of different levels at the command-line level, but the Publish Web wizard was hard-coded to use the option that generated 1 assembly per page (useful for new patching scenarios not previously available in VS 2003, but also something that generates a lot of assemblies). This could be overrided using MSBuild, but wasn't very discoverable. The Publish Web Wizard now allows developers to choose the granularity they want in the dialog -- and the default is now 1 assembly per page directory (which still provides good granularity -- but a lot fewer assemblies).
Concern #5: Is there still a way to compile user controls or standalone pages in a project and then re-use the resulting binaries in multiple web projects?
Update: This was actually supported in Beta2, but is not very discoverable (note: it was also not that discoverable in VS 2003 and not something that VS 2002/3 actually "officially supported" and tested even though it works). If you use the "fixed names" compilation option in web projects in VS 2005 you will be able to create a web project with user controls in them, compile and publish the project, and copy and re-use them in other projects (where no code-behind source code is deployed -- instead these are compiled into assemblies you deploy in your \bin directory). We'll be posting a white-paper that will walkthrough the steps on how to-do this, as well as instructions on how to create MSBuild scripts that automate this from the command line for enterprise build environments. As with the VS 2003 option (where you needed to be careful not to add a Global.asax to the project, etc), there are a set of "things not to-do" when building these types of project. But you will be able to accomplish the same scenarios.
As I mentioned in the beginning of this post, there are a lot of new features that are enabled by the new project system (I will go into these in more detail in my post next week).
Some have argued that these are primarily for "small app developers" -- I'd argue that isn't the case (although ceretainly there are a lot of advantages in there for small projects too). A few of the new enterprise scenarios now supported include: much better tool scalability for large applications projects involving 1000s of .aspx pages (whereas previously build and project load time made these scenarios impractical), support for patching compilation binaries (allowing you to hot-patch user control or page binaries without having to replace the .dll containing the code for your entire project or app), much better error detection (which is much, much deeper and more accurate than VS2003 compilation -- including compilation detection for errors in web.config and .aspx syntax markup that previously would be ignored by VS 2003 and only be discovered at runtime), richer levels of pre-compilation support (including allowing you to completely remove all run-time compilation from the equation and compile everything including the .aspx markup at build-time -- something not supported by VS2003 and ASP.NET V1.1 today), much richer command-line compilation support with MSBuild integration, and many more that I'll elaborate on next week.
The web project system is also fully integrated with the new VSTS and Team Foundation features -- so you can now automate nightly builds using the new VS build server (no need for someone to build from the IDE), run automated class unit tests, run automated web UI unit tests, calculate both block and arc code execution coverage of code, and perform performance tests and code analysis profiles against the built apps.
I'll go into more details about the web project system on Monday or Tuesday when I fly back to Seattle (where my laptop is), but wanted to quickly address some of the concerns going around.