Unlike the move from ASP to ASP.net 1.1, I was expecting the move to ASP.net 2.0 to be evolutionary rather than revolutionary; a few new controls and a reduction in the amount of code I would have to write was where my anticipation level was set. Whilst all these benefits are definitely apparent, there is much more to ASP.net 2.0 than initially meets the eye.
But I digress. In this blog entry I will address the first issue that will be most confusing to you as an ASP.net 1.1 developer when you crank up Visual Studio 2005 for the first time - the web solution structure, page structure changes and the compilation model.
First things first - there is no project file in your solution; that is why Visual Studio.Net 2005 does not include web applications as projects in IDE. Visual Studio.Net 2005 only requires the barest of information to configure the web site, and these settings are saved in the solution file.
When you first create the website, there is no assembly.info file, no bin directory, and project properties for setting information like the default namespace. So where have these files gone? The answer is that they are no longer required using the new ASP.net 2.0 compilation model.
ASP.net 1.1 introduced the concept of the code behind model, which in large finally brought order to the chaotic world of ASP, where HTML and code where mixed together into single ASP page files. The old world of ASP actively discouraged separation of logic and provided ample scope for bad programming practices to prevail. So ASP.net 1.1 remedied this issue, by providing a new code behind model, where code for server control events was compiled into a web project assembly separated from your HTML. You configured the settings for this assembly in the project properties and other assembly meta data in the assembly info file.
There were a few issues with the ASP.net 1.1 code behind model that ASP.net 2.0 addresses. All ASPX pages inherited from the System.Web.UI.Page object provide events and methods common to all ASPX pages. When you used a control event, the IDE generated the code required to assign the event handler to the event. This resulted in your pages becoming quite verbose in size, with all the required event wiring and control instantiation code visible. The entire project’s code behind code would get compiled into an assembly which would get deployed as part of your site. This compilation sometimes caused issues with the versions of the assembly used in your temporary ASP.net cache getting out of date with your most recent changes, normally resulting in you resetting IIS on your machine and deleting the Temporary ASP.net cache before recompiling. The final issue was that some bugs in your code were not picked up until the page ran through just in time compilation, so it became difficult to know for certain that your site was working until you accessed every single ASPX page in your application for the first time.
The new ASP.net 2.0 code behind and compilation model addresses all of the above issues. The first thing to know is that the code behind page uses partial classes which are new to the .Net Framework 2. Partial classes allow two classes to be merged together at run time. For the case of ASP.net, this means that the generated code required for wiring events and instantiating controls is no longer visible from the code behind, making your code much more readable. This code is now generated at compile time.
Unlike using events in the old code behind model, events are now written into the <asp: /> tags, which makes for a much more consistent approach to event wiring (making it the same as inline aspx pages).
The compilation model works by generating the relevant control and event wiring code from the aspx page and merging it with the partial class to create a class that runs under the ASPnet namespace. This is why you no longer have control over default namespace, because they all run under the ASPnet namespace (although you can use the namespace keyword on each page to specify the namespace if you wish).
Compilation can occur either using just in time (JIT) compilation, or you can now also precompile pages, either by running the command http://<servername>/<sitename>/precompile.axd, or by using the aspnet_compiler.exe application from the command prompt. Both of these commands perform the same action and compile each page in your application up front. This has the benefit of telling the developer of any build issues with the site upfront and also means that the pages do not take longer to load first time the page is accessed.
If precompilation is performed, the partial classes are merged with the generated event wiring code and put into an assembly placed in the Application_Assemblies directory (soon to be renamed back to the bin directory). ASP.net 2.0 also generates a aspx.cs.compile file which is an XML file that wires the ASPX page up to the correct assembly version.
If precompilation is not used, the Application_Assemblies directory does not store the assembly for the project, and the compiled assembly is instead placed directly in the temporary ASP.net cache where it is used from.
Because of these changes, the settings held in the old project file are not longer needed, and information such as the default namespace is no longer required. Not having a project file in a web site is also useful from a source control perspective, as the old project file contained information about what pages made up the solution, and thus adding a new page to the site resulted in the project remaining checked out for periods of time.
There are some issues with the content of the solution file however, such as it is not written in msbuild xml format, but I shall go into ASP.net 2.0 site builds in my next blog entry.