Eureka!

Many experienced developers do not like the new ASP.NET 2.0 project and compilation model at first, including myself. It was new, it was different, and I felt I had lost total control of my code base. In his post “VS 2005 Beta 2 IDE and web projects evaluation - level 200”, Jeffrey Palermo feels the new model is suitable only for the hobbyist, and is leaning towards using class library projects to develop applications in ASP.NET 2.0.

With ASP.NET 1.1, creating a web application as a class library instead of a web project was worth the trouble - if for no other reason than to get away from the infuriatingly fragile dependencies between web projects and IIS. These problems are gone in 2.0, and by taking matters into your own hands you’ll be missing out on more than just designer support.

The Moment

I realized I had the “Eureka!” moment when I could sum up the differences between 1.1 and 2.0 as follows:

In ASP.NET 1.1, the runtime code generation and compilation works for you.

In ASP.NET 2.0, the runtime code generation and compilation works with you.

Subtle difference - big payoff. What does it mean?

In the 1.1 code-behind model, all of the code-behind files compiled at the same time and into a single assembly. At some later point, a request would arrive for an ASPX page. The runtime would parse the ASPX to generate code, compile the code into a temporary assembly, and partner the code-behind class and the web form together via inheritance.

Unfortunately, the partnership doesn’t always work out. In fact, the partnership can end in the ultimate disaster - a runtime error. This can happen when a control declared in the code-behind doesn’t match a control with runat=”server” in the ASPX. This is just one example of why compiling code-behind separately from the web form makes for a fragile alliance between the two parties.

The code generation in 1.1 has no “value add”, as the cool people say. The run-time is merely working for you on an assembly line - punching together pieces to spit out HTML, but with no regard for defective parts.

In 2.0, the runtime will code-gen an ASPX page, then compile the generated code and the page’s associated code-behind at the same time, and into the same assembly. This allows the runtime to work with you, and enhance your code (a “value add”, as the cool people would say).

For example, you can have a strongly typed Master property in your code-behind by adding an @ MasterType directive to the ASPX page. The runtime will add the strongly typed property to the other half of your partial code-behind class with a new (shadows) keyword to hide the base class’s Master property. Instead of fumbling around with type casts and FindControl, we have custom tailored code for the job at hand. The code is more robust. This is what professionals expect from code generation.

Other Examples:

• No more web controls declared as fields that don’t exist in the ASP X page.
• Precompilation, including the ability to lock down updates in a production application.
• Use @ PreviousPage to give your code-behind a strongly typed reference to another web form.
• Use the @ Reference directive for strongly typed user control references
• A strongly typed Profile object
• A strongly typed ApplicationInstance property
• Only asthetics differentiate inline code and code-behind models.

I’m sure the list could go on, but this is all I’ve covered so far in the huge feature set of 2.0.

Give the new model a chance to work with you, your design will thank you.