ASP.NET 2.0 originally came without support for the ‘traditional’ Web Application project that everyone had become familiar with in ASP.NET 1/1.1. Some people liked the new approach as it affords more ‘on-the-fly’ updates, but obviously enough people ‘didn’t’ for Microsoft to release a patch for Visual Studio .NET 2005 to allow creation of WAP’s. The support was then formally re-added in VS 2005 SP1 (making the original patch redundant).
Info on the situation can be found here.
This post (as well as saving the links for me) is also a reminder of the limitations of the Web ‘Site’ model (hereafter known as WSP) and why I choose not to use it.
- Namespaces. WSP does not explicitly add a namespace to any page, class etc. It uses ‘special folders’ with some implied names (e.g. App_Code) to determine the namespace hierarchy. This whole situation can also lead to strange ‘circular reference’ errors with user controls – especially after converting from VS 2003. At the very least you’ll be pulling your hair out wondering why you can’t reference some page or control from somewhere else in your site.
- Code Reuse. Only code in the App_Code folder (and below) can actually be referenced by another class in the project. This forces a structure that you wouldn’t otherwise choose. You can of course create separate assemblies – and should in many cases.
- Unit Testing support in VS 2005. WSP does not build to a single assembly when built in VS 2005, and must be ‘precompiled’ using a Web Deployment Project which in turn uses the asp_merge (publish) utility in order to achieve this. The standard publish function doesn’t support a single assembly, although it’s possible to get the App_Code into a single DLL. This all means that because you don’t have an output at build time, you can’t run unit tests in the WSP – regardless of how much code you’re ‘reusing’ in the App_Code project. You can jump through some hoops to call the NUnit Console runner, but why bother!?
- Included/Excluded files. Because WSP doesn’t have the concept of a project file to say what’s ‘in’ and what’s ‘out’, VS 2005 uses a rather nasty ‘rename’ method of excluding files – simply suffixing the file with .exclude to denote it should be disregarded.
- References are actually just copied in. If you create a reference to an external assembly, VS 2005 will actually just copy the file into your bin folder. This means you’ll end up putting all sorts of binaries in your source tree (under source control), that you maybe otherwise wouldn’t
- Automated Build. NAnt and other automated build tools can’t work out whether a Web Site project is some sort of ‘enterprise template’ project, or a tub of lard – because it’s not really a project. This means that you can’t use the <solution> task with NAnt. you have to call a custom <exec> task instead, calling the asp_merge.exe tool, then call all other projects separately too. This all works, but again, why bother? A cynic might conclude MS was trying to cause issues for NAnt, whilst getting people interested in MSBuild.
For me, any change that introduces new ‘non-standard’ tools, just so you can have the convenience of ‘on-the-fly’ updates just isn’t worth it. You’ll actually find that this all goes out the window when you deploy to a server anyway, because depending on how you ran asp_merge, you probably won’t be able to do any ‘real’ updates because the assembly names are generated in that process and you’ll break the site by changing source files. In my opinion if you are using this approach then use the Web Deployment project and build to a single assembly to minimse these issues. If you’ve got any sort of structure around your production deployments (and you can’t just ‘copy over’) then I see literally no advantage in the WSP model, as it just seems to provide too much pain for no visible gain.
