Rick Strahl's Weblog  

Wind, waves, code and everything in between...
.NET • C# • Markdown • WPF • All Things Web
Contact   •   Articles   •   Products   •   Support   •   Advertise
Sponsored by:
West Wind WebSurge - Rest Client and Http Load Testing for Windows

Some things you lose when using Web Application Projects

On this page:

You've heard me talking about Web Application Projects a bit here and how I like this model much better than the stock ASP.NET 2.0 model.  I've been plugging away on a couple of projects over the weekend using Web Application Projects and I am really happy with this setup.


It's definitely a more formal experience working this way, back to the VS 2003 style of full builds after a change, but it's not that big of a deal. I'm working on a fairly sizable Web project here with about 80 pages in it and a fairly sizable chunk of Web related utility code and the project compiles in a few seconds. Even when debugging the startup is not a real problem.


But there are a few things that you lose when you go with WAP, and if you've worked with ASP.NET 2.0 for a while a couple of these might be a noticeable loss to you. So when I look at some of the things I lose by going to WAP, here's what I come up with:

No more Change and Run

This is the thing I actually miss the most – I'm a creature of convenience and I really liked the ability to just save and run a page without compilation. Actually page compilation is not so bad (I automatically hit Ctrl-Shift-B anyway until ASP.NET 2.0 forced me away from it with its long compile cycles <s>). That part's not so bad since compilation of the codebehind is very fast (about 3-4 seconds for my 80 page project). The real time consuming issue is debugging: With WAP you have to restart the application with each debug cycle whereas with stock projects you can make the change and keep on running with the debugger attached.


Thankfully it seems that with WAP running the actual application is much faster than previously – starting the app in Debug mode now takes only a few extra seconds whereas with stock projects it took much longer (more like 20 seconds).

No Pre-Compilation of ASPX files from within VS

With stock projects ASP.NET would compile the entire project including the ASPX pages. With WAP VS only compiles the CodeBehind pages. This means if there are errors in the ASPX pages you'll find them conveniently at runtime <s>.


Actually nothing's lost here it's just that WAP doesn't do this automatically for you. You can still run ASPNET_COMPILER.EXE against the project directory or virtual and the compiler will tell you of errors in your ASPX pages. I still find myself using my ASP.NET Compiler Utility to check for errors from time to time – definitely before any deployment.


It'd be real nice if there was a compilation option to do a 'deep compile' or something that would do a full ASPNETCOMPILER run right in the IDE and report the results. I definitely wouldn't want this on every build, but it would be useful for the occasional check to ensure that the ASPX files are clean of compile errors before you deploy. Incidentally the 'Publish' feature doesn't catch ASPX errors for some reason (or at least doesn't display it), so that's not an option at the moment.


BTW, even though WAP creates a single assembly and makes it much easier to deploy applications, you can still use ASPNET_COMPILER against your app and remove all source code from the ASPX files! So don't throw out your copy of Web Deployment Projects just yet because of WAP.

Designers don't see 'excluded' files

This is a minor thing, but unless you add files like images into your project explicitly Visual Studio doesn't let you select these files via selection editors (like ImageUrl selection for example).


No Copy Web Site

Ironic: With stock projects I never used the Copy Web Site feature because unless you did an InPlace Source Code deployment that feature was useless, as you couldn't properly copy file from another directory. Now with WAP, an InPlace deploy is actually possible because your app now has a single assembly in the BIN and the raw ASPX files that live in the dev directory. In theory at least you can deploy right from there.


Unfortunately Copy Web Site is not available for WAP. Well, maybe that's not a big loss. The tool is pretty flaky anyway and you're probably better off hotkeying off to FileZilla or other FTP client. Actually the tool wasn't all that bad functionally except it was very slow and tended to lose its connection frequently. Certainly half baked, but it has potential. Maybe somebody at Microsoft will find the time to clean it up and put it into WAP where it actually makes sense.

Not supported with Visual Web Developer

If you have applications you need to ship to other developers that might not use Visual Studio, WAP is a bad choice because it requires Visual Studio – it doesn't work with Visual Web Developer. It'd be real nice if Microsoft would roll this into the SP 1 release for VWD as well so there's consistency between the two tools.


I'm still struggling with nagging thoughts about this last issue. I have a couple of products that do go to developers and it's definitely nice to say – just go download this free tool and use that to check things out. But then this isn't the target market anyway <g>.


It's worth it!

I can live with these issues. Most are minor and mostly convenience features. I think that stock projects are just fine if you don't deal with the following scenarios:

  • Lots of Page/Control Inheritance especially between Web project Pages
  • Dynamic Loading of control and Pages

These two issues have killed me on a couple of occasions and totally painted me into a corner that I couldn't get out of without a complete redesign of strategy.


Looking at the comments to various posts I made on these issues I'm not the only one who's running into these issues. What's tough about these issues is that they are not real obvious until you run into them and when you do it's usually too late to design around it.


So for me at least I like a predictable and more simple compilation model that WAP offers, instead of the complex and very confusing 2.0 stock model. It's ironic that 90% of the time the stock model will be fine and easier to use, but woe those that run into that 10% scenario.




The Voices of Reason


Ted Jardine
May 01, 2006

# re: Some things you lose when using Web Application Projects

Would you not add "those who are tired of the pitifully slow build time" to your "I think that stock projects are just fine if you don't deal with the following scenarios" list? The one item "about 3-4 seconds for my 80 page project", to me, is it's biggest selling point. For various reasons, there are enough times that Ctrl-Shift-B needs to be hit, and waiting for it to compile the site is painful (although class libraries are fine).

Btw, following your blogs on WAP closely - appreciate you taking the time to let the rest of us know your thoughts and experiences (nice to have someone else offer themselves up as a guinea pig ;-)


Steve from Pleasant Hill
May 01, 2006

# re: Some things you lose when using Web Application Projects

Am about to convert a 1.1 app to 2.0, and have appreciated the results of the pain and suffering you have shared here.

I'm a little confused about the "Dynamic Loading of control and Pages" bullet point: I load user controls into my pages dynamically based upon various user attributes, is this something that cannot be done in 2.0 using WAP?

Omar Khan
May 01, 2006

# re: Some things you lose when using Web Application Projects

Hi Rick,

Thanks for highlighting your experienses with the "Website" and "Web Application" models in Visual Studio. I wanted to comment on a few of the things you mentioned:

1) Precompilation of ASPX files in VS
This works fully integrated withing Visual Studio if one uses "Web Deployment Projects" in combination with WAP

2) No Copy Website
The latest release of WAP does support a Copy Project command which lets one XCopy deploy any WAP project to fileshare, FTP, or http location.

As always your feedback is much appreciated. Feel free to send me an email directly at omark-at-microsoft-dot-com if you have further suggestions for us.


Omar Khan
Group Program Manager

Rick Strahl
May 01, 2006

# re: Some things you lose when using Web Application Projects

Ted, I tend to think that 3 - 4 seconds for a full project compile is pretty damn good. My solution has 6 projects and the Web project is fairly sizable so the time it takes is not out of whack. It's also roughly comparable with with VS 2003's compilation performance.

Steve, Dynamic Loading of user controls and pages and Masters is related to the pages that can't use the @Register tag to explicitly reference a page or control. So Schemes that try to dynamically load user controls out of 'template' directories are difficult to implement without hand casting controls to a specific type. The same issue applies to dynamic Master Pages loading which i described in some detail here a couple of weeks back (and which was ultimately the thing that broke the camels back). It's not a trivial problem - hard to explain in the first place - and that's precisely the point. There are so many hacks and workarounds for that one feature alone built into ASP.NET (CodeFileBaseClass anyone? @Register, @Assembly tags, a sepcial assembly for Master Pages etc. etc.) that it takes some time to actually understand the problem.

Omar, great tip. I had tried that but didn't notice that it reported errors in ASPX files. In fact, it only shows them if you make the site non-updateable which actually ends up compiling the pages. Makes sense.


Anatoly Lubarsky
May 02, 2006

# re: Some things you lose when using Web Application Projects

Rick: Edit and continue is already in and you'll see it in the next version (in a few days)

Peter Bromberg
May 03, 2006

# re: Some things you lose when using Web Application Projects

I agree (and we'll see shortly with the RTM) that WAP is a big step in the right direction - Back to the Future! Now if everything else would run as fast as VS.NET 2003 I'd be even happier...

Ted Jardine
May 05, 2006

# re: Some things you lose when using Web Application Projects

Wow. I have a completely different build time experience - you wouldn't hear me complaining if it was 3-4 seconds, but it's considerably longer (class libraries build very fast, but the Web project churns away) for me on one project, a project that would compile in 3-4 seconds in 2003.

I'll have to investigate it further to see what's up with that. It's definitely not my developer machine (AMD 64, 1.5GB RAM, etc.).

Rick Strahl
May 05, 2006

# re: Some things you lose when using Web Application Projects

Ted, are you running Web Application Projects? I don't think you are <s>. Without WAP build times for this same project are about 25-35 seconds.

June 13, 2006

# re: Some things you lose when using Web Application Projects

In Web site projects way, I have option to just deploy the dll which got code behind chnages in it, this dll won't be having anything else, that way deployment team has full trust on what's coming for deployment and they just test that page and nothing else and that way we have Quicker QA Pass and Quick deployment.

So, the WAP way, how can I avoid the regression testing for whole site when I changed just one code behind file. Right now (in VS 2003), we have to do a full regression test for whole site to make sure it didn't break anything else.

Don't you think WSP got edge over WAP here, Or I am missing something.

Rick Strahl
June 13, 2006

# re: Some things you lose when using Web Application Projects

Not sure I understand your question. WAP compiles only codebehind just like VS2003. If you want everything compiled into a single DLL you can use WDP with WAP in combination and you get the same behavior as stock with WDP.

I don't think you lose anything there with WAP - you still get both options to deploy ASPX files or deploy a single assembly that contains everything.

June 14, 2006

# re: Some things you lose when using Web Application Projects

Hi Rick, I know we see this option in the property pages of WDP, but still we can't compile a page with its code behind behind in a single dll. What all this option means is that aspx page ( html only ) will go to a separate dll because VS has already compiled all the web site code in a single dll. See what Brad explains about this in details here:

and if Brad's explaination is true, then WSP has got an edge over WAP (atleast in our scenario)

June 14, 2006

# re: Some things you lose when using Web Application Projects

To clarify my point, it was not clear before.
WSP way, we can have a single page and it's code behind getting compiled in "one single dll". So we can just deploy this "one single dll" if the changes has happened to just that page. That way we just send that particular dll to QA team for testing. That way we have quicker QA Pass because QA need not do a full regression test on the whole site, they just test a single page. But all this is not possible with WAP.
Let me know if it still doesn't clarify.

Rick Strahl
June 14, 2006

# re: Some things you lose when using Web Application Projects

Well, if that's what you want then use stock projects. Single assembly compilation is the source of all the evil that brought about the need for WAP in the first place.

You sound like you want that feature then you should also be able to live with the shortcomings of that model <g>...

June 14, 2006

# re: Some things you lose when using Web Application Projects

Rick, we are at a stage where we need to decide whether to go with WAP or WSP. I tried to explore +ve and -ves of both here:


I know you talked about inheritance related problems for WSP, but don't you think they will rectify those problems in later releases of WSP.
The main +ve I see for WAP is that it will avoid us doing huge conversion effort to WSP and still be able to use all features of VS 2005,
and the big -ve for WAP I see is no Edit and Continue support and no individual page deployment option.
We can't use edit and continue support avaialbe for WAP because it is supported only for internal web server, which doesn't fit in our root project and sub web-projects design, we have multiple teams working on individual sub web-projects, so combining all the projects in one (and hence be able to use E&C) is not the solution for us.
Can you point me to some hardcore shortcomings of WSP which can't be rectified in the future.
Thanks a million.

Rick Strahl
June 14, 2006

# re: Some things you lose when using Web Application Projects

Will they fix the stock model? I don't think it can be fixed - it's inherent to the implementation. It is what it is and while the ASP.NET might be able to make things easier with some designer magic, the issue is a core design issue that can't be just wished aside.

For issues you can look for posts on this blog. There are a a number of different posts that discuss the shortcomings - most of them related to page inheritance and dynamic loading.

June 15, 2006

# re: Some things you lose when using Web Application Projects

Hi Rick, one problem came apparent to me regarding inhertiance in WSP is that code in base page can not type cast to the derived page. In WAP we have no problem doing this. Am I right? Or something missing here.

Julien Couvreur
January 19, 2007

# re: Some things you lose when using Web Application Projects

Hi Rick. Great post and discussion!

I just got started with WAP and WSP, but I have noticed another difference.

With WSP, the template for .aspx files has a CodeFile attribute. Because of that, if you double click on say a Button element in the designer view, an event handler is automatically created in the code behind file.

But with WAP, the same scenario creates the event handler method in the .aspx (inline) instead... Adding a CodeFile attribute fixes the issue though.

# DotNetSlackers: Some things you lose when using Web Application Projects

ScottGu's Blog
July 13, 2007

# VS 2005 Web Application Project V1.0 Released - ScottGu's Blog

ASP.NET, Visual Studio, ASP.NET 2.0, .NET

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