I’ve finally gotten around to sink my teeth into ASP.NET over the last couple days and it feels a little like starting all over again trying to figure out where everything lives and how some of the cool features relate. There are many things that are very, very and useful especially in regards to the VS.NET editors and how it handles layouts and HTML that finally doesn’t move around on you or gets changed…
However, one thing that I really DON’T like is the way that VS.NET treats Web projects. In VS2005 ASP.NET Web Projects are just directories, not really projects. So when you open a project you point at a directory and VS pulls in everything from that directory and treats that as a project.
It does this – unlike VS.NET 2003 – without accessing a Web Server so in many situations it’s actually much quicker to open a project. Obviously this was done to make the process of setting up a project and getting started less error prone. This should work fine if you are building a site from scratch with ASP.NET in mind and your project isn't huge.
But this is a major problem with an existing site. I’ve been wanting to rebuild my main site to be a bit more dynamic than it has been, so this is one task I’m using to get a feel or some of the new features. Basically I need to add a few ASPX pages to the site where there previously were ASP pages.
So when I open Web Project against my existing Web site directory I’m treated to about 3-4 minutes of load time as it’s pulling in my entire site into VS.NET. Yup, HTML Pages, static XML files, images, stylesheets. EVERYTHING! Worse, it pulls everything including all subdirectories, including those that are actually virtual directories that contain separate Web applications. (more on that later).
For my main WebSite this is a easily a few thousand files so no wonder this is slow. I don’t really need ASP.NET to manage my site for me or be like FrontPage. Although that would be OK if it actually had a better HTML editor and more site management features, but as it is ASP.NET is a dev tool not a site manager and I think it is much more useful to have VS manage only what you add rather than trying to bring everything into a project.
The worst of it is this though: Once everything is loaded and I try to edit any code page (ASPX, Global.Asax, ASCX files etc.) VS.NET just crashes. (Later: After some more experimentation and opening a non-code file first editing code pages seems to work fine. But there’s definitely a problem opening a code page first). This appears to be some resource related bug as it fails only in this large project. In the sub project I was originally using for testing which just had a couple of pages all is fine.
In addition having a project that is directory based also has other problems. ASP.NET tries to compile your code in the directory, not based on a project structure. What this means is that if you made some backup copies of files, ASP.NET will happily compile those pages for you and in the VS.NET IDE complain that this class already exists in the ‘project’ since you now have duplicates.
The default compilation model for ASP.NET in 2.0 is to look for ASPX pages and compile them as needed along with any references to the ‘CodeFile’ attribute reference. There’s no true pre-compilation and no single assembly to deploy in this mode, but rather the compilation happens as pages are going to the server. Now if you have CodeBeside pages (CodeBeside = ASPX + Partial Class compiled into a single class assembly) those need to be deployed too.
There are also precompilation and batch modes available which allow you to deploy a site either with just the ASPX pages (similar to the way VS.NET 1.x worked with CodeBehind assemblies) or no ASPX pages at all with all code compiled into a single assembly. The latter sounds like a great low maintainence way to make sure everything goes up to your site.
But again you are likely to have problems if you want to pre-compile something like my huge Web site. Because now even though I added two or three pages, ASP.NET is trying to compile all ASPX pages in the project tree. I don't think so.
There’s been a lot of discussion of the code models and there are a lot of choices now. It’s not immediately obvious which choice will be for you.
- ASPX Inline Code Compilation (all ASPX)
- ASPX with CodeBeside Files (ASPX + .cs with Partial Classes)
- ASPX with CodeBehind Files (ASPX + .cs with inheritance)
- Precompiled ASPX files
- Batch Compiled Applications
And some of these can work in combination. This is not a step forward but rather a step back IMHO. Giving too many choices, many of which are nearly identical, is confusing and requires experimentation to find what works best. There shouldn’t be more than 2 maybe 3 choices for compilation.
In my situation I can’t get any of the precompilation modes to work at all because I cannot get my project to compile completely. Why not? Well ASP.NET is going into subdirectories of my root Web some of which are ASP.NET sub applications. There are web.config files there that contain directives that are not valid for subdirectories. In a real Web environment this is not a problem because the virtual directory boundaries identify these as separate. But for the directory based project manager it has no idea.
There's another problem related to the web.config of 2.0 interfering with a web.config of 1.1 but I'll post that separately in the next post. Incidentally my version of .TEXT .94 also doesn't run correctly with .NET 2.0 - some of the complex inheritance schemes Scott's using apparently doesn't jive in ASP.NET 2.0.
This is not looking good...