In VS.NET 2005 ASP.NET projects are no longer real VS projects, but rather a mere directory representation. This has some advantages the most significant of which is that Webs can now open without the need of a Web Server or FrontPage extensions.

But it appears that this change also has some serious implications of how VS.NET treats your project resulting in different behavior for ASP.NET project files compared to other projects.

Problems with Root Webs and Sub Webs

The most annoying to me is the fact that you cannot limit what VS.NET imports into a ‘project’. A few days ago I decided to move my root Web to ASP.NET 2.0 to add some dynamic features I’ve been meaning to add for some time to remove some of the COM routines I use on my site for counters, logging and a few other housekeeping tasks.

The import resulted in 4000+ files getting pulled into my ‘ASP.NET project’. Worse it pulled in all subdirectories which are unique Web applications in virtual directories by themselves. So it pulled in sub applications, like my West Wind Web Store, my Bug Reporting interface, my WebLog, the Message Board – everything. In addition it pulled in my photoalbum with its huge number of pictures.

This is not a good thing as it completely blows away any separation that you have between applications. You’re supposed to manage this with IIS virtual directories, and sure enough tools like FrontPage – which is a true site manager – understands these boundaries and represents these sub applications separately. VS.NET however does not.

This is a major problem because for existing large root sites this makes using VS.NET a non-starter. Here’s why:

It’s slow

Loading 4000 files is dog slow as VS has to parse everything into the project tree. In Beta 2 it takes about 2-3 minutes to open this ‘project’. It also makes VS.NET unstable as hell and resource usage is enormous.

It’s unmanageable

Having that many files in a project is a mess. VS.NET is supposed to be a Web Developer tool, yet adding all of these files have nothing to do with the development process. Worse, VS.NET doesn’t do any sort of site management features to make it even remotely useful to show all of these files. Instead the ASP.NET error trapper makes even more of a mess of things by looking at all broken links and HTML errors and mixing those in with real code errors when you compile the project. It’s highly unlikely an existing project will ever compile when there are subdirectories with other apps in them.

Completely unrealistic for deployment

ASP.NET 2.0 uses a new deployment model and there are really just two ways to do this: Deploy with source code (same as local) or precompile the site. Source Code distribution is not really an option on a live site and precompilation with this large site of 4000 files is not even an option. Remember that precompilation will fail anyway because if you compile a root web ASP.NET will not stop at virtuals. So compiling my root web actually compiles the root, my West Wind Web Store, my Bug Reporting site etc. anything that lives below root directory. Precompilation is based on the concept of full deployment of the precompiled output – which means you have to deploy everything, including sub-webs all at once. NO WAY DOES THIS WORK!

This is a major blunder on ASP.NET’s part IMHO, something that was obviously overlooked. The easy solution to this problem would be to force the precompiler to respect virtual directories. There's no such option now. Your alternative? The only one I see is to go through your Web root directory and move any sub-virtuals out of the root Web directory and remap them to a separate path. This is lame and should not be necessary.

I did report a related issue to the MSDN Feedback Center and was denied stating the is by design:

http://lab.msdn.microsoft.com/ProductFeedback/viewfeedback.aspx?feedbackid=4a4630b4-6f7c-4ff6-bf37-3d887f8a4aff

Changed Go to Definition Behavior

There are also a number of things that ASP.NET projects do differently than other projects because ASP.NET projects are not real first class projects in VS.NET 2005. One really annoying behavior is that the Goto Definition functionality in the code context menu no longer takes to the definition of a class if it’s in another project.

So, for example, right clicking on a business object method where the business object lives in a separate project brings up a pseudo class view:

In Vs2003 the same operation would take you to the actual class in the other project and place you at the code definition. This view above is a read only view that doesn’t do anything for you.

If you don’t like this behavior you can vote on this at the MSDN Feedback center here:

http://lab.msdn.microsoft.com/ProductFeedback/viewfeedback.aspx?feedbackid=f7634916-f604-41c9-a1cf-ac5aeebc3e26

No Class Viewer in ASP.NET projects

Another related issue is that the Class Viewer is no longer available to ASP.NET pages – the option is missing from the Code context menu when editing an ASP.NET CodeBehind page. This goes for anything in a Web project including Web Services. For Web Services though you can use the Class Viewer to see the class, but there’s no Synchronize Class View option to get there quickly.

This is a by necessity issue and a side effect of the new page compilation model because the pages don’t exist until the compiler creates the code for them at compile time, but still this is an annoying loss.

It seems like the ASP.NET codebehind editing experience has taken a few steps backwards.