Web Site Projects

I've never liked Web Site projects. It's not that I've ever really had a reason to despise them, I've just always chosen Web Application Projects if given a chance - even in the pre SP1 days when they came as an additional install. Now, after being forced to use them for a few months (in one of those "not my architecture" situations) I've come to be able to put names and faces to all the reasons I'd subconsciously discriminated against them in the past.

Firstly, the time delays in building - by default, with large projects the build time can just get a bit too slow. Sure you can mitigate this by optimising some build settings (more optimisations settings listed here), but they still just feel too slow.

Secondly, the cumbersome way references seemed to be managed. I know where the references page lives in Web Site Projects, but I just don't quite get why it needs to be that much more awkward to use than web application projects or any other project for that matter. 

Next, the background compilation - some people might think this is a plus point! Personally, I hate it. I've watched a few people get confused by this, to the point where they're not sure whether they need to build or not! This is probably more the fault of the developers in question, but I'm on a roll here so I'm going to blame Web Site Projects for making them confused in the first place. In reality, it's probably more a case of getting used to a certain way of working, I can adapt, but it's painful to watch people who can't. Background compilation is less of a useful point for me because ReSharper gives me this anyway - regardless of what UI project type I'm using.

Finally, this little gem. An error message which looks something like:

The base class includes the field 'MyControl_1', but its type (MyControl) is not compatible with the type of control (ASP.MyControl_ascx).

I fixed this by messing about with the Publishing options - however different options seemed to work for me than did for others, namely turning on fixed naming (which makes sense really). My bugbear is that this problem just randomly started happening one day after many months of it not being a problem at all. Same deploy process. Same projects. Probably some minor changes, but none to any of the controls or pages which were breaking. Just good old randomness.

It's the straw which broke the developers back by occuring at the best example of the "wrong time" ever possible. It seems to be an issue with IIS6 and IIS7 - I was using IIS7, and found that moving every single item in the Management UI around made troubleshooting a lot more painful. If you're in the same situation, then you might find this list, which maps IIS7 configuration options with their IIS6 counterparts to be useful. Finding yourself needing to troubleshoot IIS in a hurry but starting at an entirely foreign console is an interesting experience - I guess it's how most developers feel when they look at IIS, but I'm not used to feeling like that much of a n00b..

I'm sure there are more reasons to hate Web Site Projects, I just haven't discovered them yet - hopefully, I won't get a chance to!


Link: VS 2005 Web Project System: What is it and why did we do it?
Link: The base class includes the field 'MyControl_1', but its type...


Posted on Thursday, September 06, 2007 11:11 PM | ASP.NET Web Development

Like this? Share it!

No comments posted yet.

Post a comment
Please add 1 and 6 and type the answer here:
Remember me?
Ensure the word in this box says 'orange':