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:
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.
Other Posts you might also like