Rick Strahl's Weblog  

Wind, waves, code and everything in between...
.NET • C# • Markdown • JavaScript • Angular
Contact   •   Articles   •   Products   •   Support   •   Search
Ad-free experience sponsored by:
ASPOSE - the market leader of .NET and Java APIs for file formats – natively work with DOCX, XLSX, PPT, PDF, images and more

ASP.NET projects aren’t 'real' projects in VS.NET 2005

On this page:

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:





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:



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.

The Voices of Reason


May 27, 2005

# re: ASP.NET projects aren’t 'real' projects in VS.NET 2005

Wow, this behavior is lame. I can understand that this may be easier for simple projects and deployment, but for larger apps it's just stupid. Even though my app is not in the root, I still have several forms and classes that I routinely remove from the project (as they may be works in progress) before I compile and deploy. I guess I'll have to move them out of the folder sturcture every time. What a pain.

Shannon J Hager
May 29, 2005

# re: ASP.NET projects aren’t 'real' projects in VS.NET 2005

the comment I just left on that issue:

This is going to be a TERRIBLE problem for every current ASP.NET developer who uses shared hosting. Anyone who has multiple projects/applications under the root of their web will now be prevented from upgrading to ASP.NET 2 without moving to a new host or completely ripping their webs apart and reworking the folder structure and getting their host to set up the virtual folder mappings. Most shared hosting/virtual hosting companies do not allow this (or at least do not allow it without contacting them and having them do it manually), so unless I am reading this issue incorrectly, the issue with subwebs is going to create a huge migration problem for those of us that host sites on virtual hosting/shared hosting plans.

Rick Strahl
May 29, 2005

# re: ASP.NET projects aren’t 'real' projects in VS.NET 2005

Shannon, this is another good point I hadn't even considered...

You can kind of work around that particular issue though by creating your app in development isolated and uploading it indepedently (ie. without the 'sub-webs'). You can then upload the sub webs into their virtual directories independently.

ASP.NET's runtime operation actually doesn't cause any problems - it's the compile time behavior that's the problem because the ASP.NET compiler doesn't understand sub-web boundaries.

This means you have to really think about isolating your Web applications, which IMHO is a ridiculous requirement especially since the behavior was correct in ASP.NET 1.1.

OdeToCode Links
June 12, 2005

# OdeToCode Links For June 12

June 18, 2005

# re: ASP.NET projects aren’t 'real' projects in VS.NET 2005

you think Microsoft is a fool???? think again !! May be its the other side.

Tyler Carver
June 27, 2005

# re: ASP.NET projects aren’t 'real' projects in VS.NET 2005

I'm glad other's see what a huge problem this is creating for some ASP.Net developers.

I have used ASP.Net 1.1 to build a plugin architecture that allows me to drop a directory with ascx files into a Framework Web project. The framework has the aspx pages that load the different plugin ascx pages. This works because of everything being precompiled and that 1.1 excludes everything from the project by default.

Don't even get me started to what this is doing to our source control and team setting.

Here are the bugs MS has open for this issue. Just from a project perspective:
Bug Details: Exclude From Project / Include In Project not available in VS 2005 Web Applications

From a VSS perspective:
Bug Details: VS Assumes All Files Under a Web Site Project Are To Be Checked Into Source Control

Also check out http://forums.asp.net/962755/ShowPost.aspx.

It looks like there is such a major change to 2.0 that many of our 1.1 project just can't be ported and we will have to start from scratch with this new architecture. I cannot afford to switch at this time.

July 11, 2005

# re: ASP.NET projects aren’t 'real' projects in VS.NET 2005

And... How we can split work for 2 or more developers ??

August 25, 2005

# re: ASP.NET projects aren’t 'real' projects in VS.NET 2005


I'd recommend checking out this post: http://weblogs.asp.net/scottgu/archive/2005/08/23/423409.aspx

This walksthroughs opening and using web projects in IIS.

The problem you are reporting above is that you are opening up the root website as a file-system web -- in which case there is no way to know the virtual boundaries for sub-applications.

If you open it up as an IIS web the sub-application boundaries are fully honored, and you will have multiple partitioned web applications like you do today with VS 2003. Sub applications are ignored, and path boundaries are honored.

Hope this helps,


P.S. To answer two questions above, exclude from build will be supported in the final release.

Rick Strahl
August 25, 2005

# re: ASP.NET projects aren’t 'real' projects in VS.NET 2005

Thanks Scott... This helps tremendously in understanding how to get at the project structure properly.

October 17, 2005

# re: ASP.NET projects aren’t 'real' projects in VS.NET 2005

I got the RC VS2005 installed and running VS is slow as hell especially for asp.net (I have 2003 installed as well). Debugging web service is way too slow as well.

I am installing on a fresh machine to see if it will run faster.

October 26, 2005

# re: ASP.NET projects aren’t 'real' projects in VS.NET 2005

Well, I see a lot of screaming and crying here - 'oh my God, it does not work the same way I expect it!'.. Seriously, guys, if you could not figure out that the way you're opening your web app in the IDE is a wrong one, then at least ask whether you're doing something wrong at first, and only then start bitching.. It's quite sad to read this...

Tyler Carver:
VSS? Are you serious? Oh my God... If you are using this THING, then I wonder what kind of projects you're creating...

Rick Strahl
October 26, 2005

# re: ASP.NET projects aren’t 'real' projects in VS.NET 2005


If you're NOT using the IDE to open your visual files and take advantage of the tools Microsoft provides to make page development easier then YOU are most definitely missing a large part of developer productivity.

Have you even looked at 2.0? Your message sounds like an ignorant goad of somebody who either doesn't use ASP.NET at all or at least hasn't looked at 2.0.

Rick Strahl's WebLog
October 27, 2005

# VS.NET 2005 Web Project Manager Tool

Microsoft has heard some of the complaints about the ASP.NET 2.0 project deployment issues and they are planning to release an Add-In project type that provides the missing features to control deployment much better.

Ayende Rahien
November 01, 2005

# re: ASP.NET projects aren’t 'real' projects in VS.NET 2005

I'm //sufferring// here because of this.
Any idea when we'll have this?

Rick Strahl
November 01, 2005

# re: ASP.NET projects aren’t 'real' projects in VS.NET 2005

I just got Word that we'll get it on the official release date next week...

November 07, 2005

# re: ASP.NET projects aren’t 'real' projects in VS.NET 2005

Though this is a good idea, and i like it for small projects, MS should have provided the other option too.

Hope MS adds on the vbproj support and leave the option to users.. if they want to create vbproj or the folder structure...

November 07, 2005

# re: ASP.NET projects aren’t 'real' projects in VS.NET 2005

BTW, as some have mentioned, running VS 2005 is very slow. The opening itself takes some 30 sec to 1 min. No idea why it take so long for even a small vb project to open.

November 08, 2005

# re: ASP.NET projects aren’t 'real' projects in VS.NET 2005

Ok, instead of right-clicking in the VS 2003 IDE and selected to exclude the file/folder in the project, all we have to do in VS 2005 is open the IIS MMC and create virtual directories in IIS for folders. Then open Windows Explorer and right click on each file, select "properties", and change the hidden attribute on each and every file to hide them.

This is freaking ridiculous. This just made a simple 1 second process into at least several minutes worth of tedious adjustments everytime some files or folders are added that I don't want to be included in the source control.

I hope someone creates a real workaround for this. What a nightmare.

Rick Strahl's Web Log
October 15, 2006

# ASP.NET 2.0 Project Deployment Tool is here - Rick Strahl's Web Log

Microsoft has finally released the Web Deploment Projects Add-in that promises to bring back some of the missing flexibility of ASP.NET 2.0 Web projects...

# DotNetSlackers: ASP.NET projects arent 'real' projects in VS.NET 2005

Getting Started
February 27, 2007

# ASP.NET Forums - Need a reality check: ASP.NET 2.0 and Root Web Deployments

West Wind  © Rick Strahl, West Wind Technologies, 2005 - 2021