In the .NET 2.0 app I'm working on, I finally got to a point in the project where I could try it out (a full 12 hours before release!). I followed Scott Guthrie's directions to upgrade an existing VS2005 web site (I'm a C# guy; Scott has directions for VB too) and was quite pleased with them overall--easy to follow, didn't leave much out.
First, the things I like about WAP:
- Namespaces: In a VS2005 web site, newly added files don't get a namespace, which is kind of kludgy if you have a VS.NET 2003 project with namespaces specified for every page and control, then upgrade to VS2005, and add new pages and controls and have to leave them in the default namespace, or manually put that code in (or maintain the VS2005 file templates manually). WAP lets you specify and modify default namespaces again.
- AssemblyInfo.cs and generated code files: I'm a pretty picky developer and I like being able to specify properties for my assemblies myself, and see all the code that goes into that assembly, and WAP makes that easier. You see the MyPage.aspx.designer.cs files in VS's Solution Explorer, which contain the wireup code that was mixed in with the regular code-behind file in VS.NET 2003, and generated and compiled behind the scenes in VS2005 web sites.
- Faster compilation: My web app is rather small, but it was still noticeably faster to compile it as a WAP rather than a web site. According to Scott:
VS 2005 WAP build times are significantly faster that Web Site Projects – in some cases 10x or more. That is because WAP projects only compile the code-behind of the project and standalone classes (like VS 2003 did). Web Site Projects do deeper compilation and verification, which is nice, but which does slow things down. There are several settings you can change to modify this, but WAP projects will always compile fastest.
Note that I'm only talking about building the project in VS, not the JIT compilation from MSIL to native code that happens when you first pull it up in the web browser; that speed didn't appear to change in my case.
Here are a few snags or "opportunities for improvement" (to use a more overly politically correct term) I found in upgrading from a VS2005 web site to a web application project:
- One thing Scott did seem to leave out of his directions is how to convert web references. I had to dig out an URL, have VS2005 recreate the web reference, and then make some manual changes (since Reference.cs is apparently dynamically generated with a web site project, so I couldn't use it for, um, reference). Unfortunately, this is the way to do it for now (which would be a real pain if you listened to Microsoft's marketing a few years ago and used web services for darn near everything!), though they're considering automating that conversion in future versions.
- Another thing the directions don't take into account is source control. I don't know if it's not expected that a large enough portion of the audience will be using source control to warrant including that in the directions, or because they're keeping it simple. As it is, I didn't want to lose my files' history (and didn't want to mess with branching, especially since I'm using the source control in Team Foundation Server), so I moved from the site to the project instead of copying, and crossed my fingers I didn't break anything. So far, so good--the site's working great on my development machine.
- Having upgraded my application from VS.NET 2003 originally, I had a Global.ascx and Global.ascx.cs; I moved the latter to App_Code and manually changed the former to inherit from it. So I manually moved that back when moving it to a web app project. I'm not sure if that's a common practice that would be worth including in the instructions, or just the weird way I did it when moving from VS.NET 2003 -> VS2005 web site. Also, when I double-click on Global.ascx in VS2005, it refuses to open that file, opening Global.ascx.cs instead. To change Global.ascx, I had to open it in Notepad (*gasp*).
- We have a third-party component (Aspose.Excel, now called Aspose.Cells) that uses a .lic licensing file. I'm not sure we've ever (in VS.NET 2003, VS2005 web site, VS2005 web app) handled this the "right" way--pretty much just get it working and then leave it alone. I got it working this time by copying the file from the web site project's bin to the web app project's bin via Windows Explorer. I was hoping there would be a best practices way (probably using VS2005) to get this .lic file copied to the bin directory; I looked on the component reference's properties and didn't see anything obvious. No such luck for the time being.
Overall I'm happy with it, and would definitely use a web application project for a new VS2005 project over the web site model. I'm kind of a low-level, class library developer sort of guy, so it's nice to have namespaces, AssemblyInfo.cs, generated code files in the solution, faster compilation, etc. back.