I set up a new project tonight and I decided to give the ASP.NET 2.0 Web Application Projects Add-in a go. This tool basically provides VS 2003 like project experience where you add files to the projects manually rather than letting VS.NET automatically pull everything in for you. This is a good thing for non-trivial projects especially those that sit in a directory hierarchy.

The two reasons I'm considering it is for simplified deployment of applications and the ability to keep unwanted files out of my project.

The way this works is that this project syncs up the control definitions in a .designer file with a separate partial class in a way similar to the way Windows Forms 2.0 work. Changes in the designer are persisted in the .designer file, which contains control references and event hookups – the stuff that used to be stored in InitializeComponent -  and wraps it in another partial class. By default ASP.NET 2.0 does this 'dynamic creation of controls classes' at compile time which can be either at runtime or if you're using the ASPNET_COMPILER.EXE utility. With this tool the generation is done at design time and the .designer file is created to hold presumably the same code. One nice side effect is that you can see what is generated. I suspect the same compilation algorithms are used that are used for runtime compilation so I expect the quality of the generated code to be as reliable as the live compiled code.

To me this just feels like a much more natural approach to develop. I'm back to compiling my projects and seeing the results of a compile in a second or two, instead of waiting for a ASPNET_COMPILER (or internal equivalent) to do its thing as is the case with stock ASP.NET 2.0 projects. Granted my project is still small but I would expect that even with a sizable project performance is likely to be similar to what we saw in VS2003.

For small and trivial projects, the File based approach is easier to use no doubt, but for larger project I think it'll be cleaner and a faster development experience to use this toolset. But understand this model means – just like VS2003 – that you *have to* compile your project in order for any change to a CodeBehind page to take. It also doesn't compile the ASPX pages – so unlike the stock model the compiler cannot check for errors in ASPX pages should you have expressions or code snippets lodged in your ASPX page.

The tool works, but it's still a bit rough. ScottGu has posted a list of known issues all of which I ran into before looking at his page <g>.

Here are a couple of more that aren't listed. VS.NET complains about the use of the CodeBehind attribute in pages and issues a warning. NBD. The next is a bug that's a little more serious: I use some entries in Web.config to automatically pull in my support controls so I don't have to @Register tags to my pages when adding controls:

  <system.web>

      <controls>

        <add tagPrefix="ww" namespace="Westwind.Web.Controls" assembly="wwWebControls"/>

      </controls>

    </pages>

  </system.web>

instead of using a <%@ Register %> directive in the page.

This works fine for running code, but Web Application Project generator fails to load the controls. When the @Register directive is missing from the page it fails to synchronize the pages properly. In fact it looses ALL control definitions including all stock controls and events in the .designer class. If there's anything funky with a control Register tag the .designer file will get wiped of all control and event hookups. This even though the page compiles and runs fine so it took a while to figure out what was going on. Adding the @Register directive into the page fixes the problem.

So now it's tradeoff time:

Pros:

Easy VS2003 deployment model – one assembly created

Quick project compilation

Only files you want are added to the project

Full project support – MSBUILD, Xml Comments etc.

You can see the ASP.NET generated code

Cons:

Doesn't compile ASPX pages so no compile time error checking on ASPX code

Doesn't work with Visual Web Developer – so redistribution is an issue

You *have to* compile for any CodeBehind Change

Making a change during debugging requires restarting your debugging session

As I worked with this today, I realized that I have gotten used to some of the nice things in the stock ASP.NET 2005 projects. The fact that you don't have to compile is nice and that you can debug, make a change without restarting the app also is sweet.

But I definitely like the fact that I can compile my project in one quick shot and see all errors, as well as the ability to get a single assembly I can easily deploy. I'm back to being able to deploy my app out of the development tree and no more cumbersome ASPNET_COMPILER.