Dynamic Compilation

ASP.NET 1.x already supports dynamic compilation of pages and user controls ( .aspx and .ascx files), eliminating the need for an explicit compilation step. Pages are compiled the first time they are requested by a user, when they are changed, or when any of their dependencies (such as web.config or global.asax ) are changed. Files with no explicit dependency, however, do not trigger this compilation. This includes components (assemblies in the \bin folder and their source), resource files, Web Services, and so on. Not only do they not trigger their target ASP.NET pages to be compiled, but they also aren't compiled automatically. They require a manual compilation stage, which invariably means a batch file to compile them or the use of a make system.

ASP.NET 2.0 improves dynamic compilation by supporting an increased number of files. Stand-alone classes, Web Services, typed data sets, master pages, and themes can now be automatically compiled without the need for manual intervention. There are two real benefits to this approach. First, developers can concentrate on just coding. Saving your files to the appropriate folder means your Web applications will always be up to date. Second, when using Visual Studio .NET "Whidbey" there's no need for an intermediate compile stageyou don't have to build the application to use it, you can just hit the Refresh button in the browser.

New Folders for Dynamic Compilation

Developers tend to follow the same style for laying out the folders in Web applicationsan \Images folder for all of the site images, perhaps a \Components folder to store user controls or source for data layers , and so on. The expansion of dynamic compilation introduces some fixed folders.

• The \Code folder is for storage of class files ( .cs or .vb ), WSDL ( .wsdl ) files, and typed data sets ( .xsd ). Placing files of these type in the \Code folder will enable them for automatic compilation.

• The \Resources folder is for storage of globalization resources ( .resx and .resources ). Resource files can also be stored in the \Code folder.

• The \Themes folder is for storing themes and skins ( .skin ).

Using these fixed folders allows the ASP.NET compilation process to automatically compile files as part of its normal compilation of ASP.NET pages.

Using the \Code Folder in Visual Studio .NET "Whidbey"

The \Code folder is fully supported in Visual Studio .NET "Whidbey", and its use is simply a matter of creating the folder. Code classes can be added, as shown in Figure 2.15.

Figure 2.15. Creating classes in the\Code folder

A great use of the \Code folder's automatic compilation is for placement of business objects. For example, consider Listing 2.3, which shows a class to handle data from an authors table ( Authors.vb ).

Listing 2.3 A Simple Business Component

 Imports System Imports System.Web Imports System.Data Imports System.Data.SqlClient Namespace Pubs   Public Class Authors     Public Function GetAuthors() As DataSet       Dim conn As New _        SqlConnection("server=.;database=pubs;Trusted_Connection=True")       Dim da As New SqlDataAdapter("select * from authors", conn)       Dim ds As New DataSet       da.Fill(ds, "Authors")       Return ds     End Function   End Class End Namespace 

We can simply use this code from within our existing pages, perhaps by using an ObjectDataSource to bind directly to the class, and then by using a grid to bind to the data source, as shown in Figure 2.16.

Figure 2.16. Binding an ObjectDataSource

Folder Hierarchy

The hierarchy of these folders can be configured depending on requirements, but there are some rules. At the top level the names cannot change, and they must be underneath the application root. Within the folders, though, there are some options.

The \Code Folder

There is no restriction on creating subfolders to organize your code. For example, consider the following application structure:

 c:\Inetpub\wwwroot   Default.aspx   \Code     Authors.vb     \Utilities       Tools.vb 

Here we have Authors.vb at the top level of the \Code folder and Tools.vb under the \Utilities folder. Both files will be dynamically compiled and linked to the target assembly. This means that types within these classes are automatically available from any other page within the application. You therefore don't have to use namespaces and import them in your ASP.NET pages, meaning new code files can just be dropped into the \Code folder for them to become available for use.

Supporting Multiple Languages

By default the \Code folder supports only a single language (since everything is compiled into a single assembly), no matter what the hierarchy of subfolders. However, this behavior can be configured through the application configuration file, as demonstrated in Listing 2.4.

Listing 2.4 Configuring Compilation Directories

 <?xml version="1.0" encoding="UTF-8" ?> <configuration>   <system.web>     <compilation>       <codeSubDirectories>         <add directoryName="vb_code" />         <add directoryName="cs_code" />       </codeSubDirectories>     </compilation>   </system.web> </configuration> 

This instructs the compilation system to produce separate assemblies for files under the two directories, and therefore they can contain different languages (although they are still restricted to a single language per directory). For example, our folder hierarchy could now become:

 c:\WebSites\MySite   Default.aspx   \Code     \vb_code       Authors.vb       \Utilities         Tools.vb     \cs_code       Interop.cs 

Folders added to the codeSubDirectories section of the configuration file are only a single layer deep. Thus you cannot code:

 <add directoryName="vb_code\utilities" /> 

You can, however, have a deep hierarchy underneath the top level, but all code files will be built into a single assembly for that folder.

The assemblies created are not placed in the \bin directoryindeed, with this system there is no need for a \bin folder, although the \bin folder is still supported and should be used for scenarios where dynamic compilation is not required or supported. Automatically compiled assemblies are placed in a folder managed by ASP.NET, so you don't even have to worry about where they are. If deployment is intended, then pre-compilation is required, and that is covered a little later in the chapter.

Web Services

In ASP.NET 1.x, Web Service proxies had to be manually created, usually by use of the wsdl.exe tool, or by including a reference in Visual Studio .NET. In ASP.NET 2.0, Web Services are catered for by including WSDL files in the \Code folder. With automatic compilation, a proxy class is automatically built from the WSDL file and linked to the default assemblies, and the service can be called directly from ASP.NET pages.

Typed Data Sets

Typed data sets provide strongly typed access to data, either from XML files or DataSet s. Like Web Services, in version 1.x these had to be manually generated (using xsd.exe ), but they follow the same pattern as WSDL files in version 2.0. All that's required is for the XSD file to be placed in the \Code directory, and the proxy will be generated automatically.

The \Resources Folder

The \Resources folder allows for easy globalization of applications. Under ASP.NET 1.x, resource files were manually compiled and placed in the \bin folder, under subfolders named for the culture of the resource.

In ASP.NET 2.0, resources can be placed into the \Resources folder, where they are then compiled as part of dynamic compilation.

The \Themes Folder

As mentioned in Chapter 1, themes provide a way to supply different UI styles to controls. Since themes can be set at runtime they are late compiled when required. A local themes file is used only for local themessite-wide themes, such as those supplied by standard in ASP.NET 2.0, are held in a central location.

Themes are covered in detail in Chapter 7.

Configuring Compilation Options

The dynamic compilation system allows configuration through web.config . Earlier we talked about the codeSubDirectories section allowing configuration of folders and target assemblies. Table 2.1 shows that there are also batch options available as attributes to the compilation element.

Table 2.1. Compilation Configuration Options

Attribute	Default Value	Description
batch	true	Indicates whether or not batch compilation takes place.
batchTimeout	15	The number of seconds for compilation to take place. An exception is thrown if this time is exceeded.
maxBatchSize	1000	The maximum number of pages/classes compiled into a single batch.
maxBatchGeneratedFileSize	3000 K	The maximum size (in kilobytes) of an assembly.

Custom Builds

Like much of ASP.NET, the build process is extensible, using build providers targeted at specific file extensions. These are configured by default in machine.config and can be added there or within web.config . For example, the <compilation> section could look like Listing 2.5.

Listing 2.5 Configuring Build Providers

 <configuration>   ...   <buildProviders>     <add extension="*.aspx" appliesTo="Web"          type="System.Web.Compilation.PageBuildProvider" />     <add extension="*.wsdl" appliesTo="Code"          type="System.Web.Compilation.WsdlBuildProvider" />   </buildProviders> </configuration> 

Build providers are also inferred from the compilers section of the configuration, so there are no explicit build providers for code files. The extension applies to the folder in which dynamic compilation applies. The appliesTo attribute indicates the folder in which the build provider applies, where Web indicates general Web folders. Multiple folders for build providers are supported by simply separating the folders in the appliesTo attribute with a comma.

This system allows custom providers to be built for types not known to ASP.NET, allowing specification of selected directories for those files.

Build Order and Life Cycle

Dynamic compilation builds automatically; therefore, understanding the build order is important to ensure that dependencies are not missed. The build order is as follows :

• The \Resource folder and other resource files

• The \Code folder and other code files

• Global.asax

• Resource files outside of the \Resource and \Code folders

• Individual Web files, such as ASP.NET pages of Web Services

The life cycle of pages and the application is also affected by dynamic compilation because updating a file can result in more than just a single page hit. Table 2.2 details what happens when files are changed, whether recompilation takes place, and whether the Application Domain is restarted. Recompilation will also take place if the <pages> and <compilation> sections of web.config are changed.