A First Look at ASP. NET v. 2.0 2003
Authors: Homer A., Sussman D., Howard R.
Published year: 2004
We saw earlier that files created with code separation now show in Visual Studio .NET "Whidbey" as two files. In ASP.NET versions 1.0 and 1.1, the code-behind model allowed separation of code from content, and in ASP.NET 2.0 this model has been changed to simplify development. Instead of the content page inheriting from the code-behind page, we now specify which code-behind file is to be compiled with the content file. That may seem like just a change in semantics, but it's actually a more fundamental change, made at the Common Language Runtime (CLR) level.
Version 2.0 of the CLR provides support for partial classes , where the same class can span multiple files. This allows the code-separation page to be far simpler than in previous versions because it can be part of the same class as the content page, meaning no more public variables are required to reference the controls on a page.
The implementation of this is easy. Consider the page for Authors.aspx (Listing 2.1).
Listing 2.1 Using Code Separationthe ASP.NET Page
<%@ Page compileWith="Authors.aspx.vb" className="ASP.authors_aspx" %> <form runat="server"> <asp:Button runat="server" onClick="button_Click" /> <asp:Label runat="server" id="Message" /> </form>
Because of partial classes, the code-separation file ( Authors.aspx.vb ) is simple, as shown in Listing 2.2.
Listing 2.2 Using Code Separationthe Code-Behind File
Namespace ASP Expands Class Authors_asp Sub button_Click(Sender As Object, E As EventArgs) Message.Text = "You pressed the button" End Sub End Class End Namespace
Partial classes have introduced the new Expands keyword, indicating that this class is not self-contained and is part of the Authors_asp class. For the content page, the compileWith attribute defines the physical file containing the code to compile along with the content page, and the className attribute indicates the name (including the namespace) of the class. When the className attribute of the content file and the namespace and Class of the code file match, code for both files is compiled into a single class.
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.
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
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.
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.
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
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 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.
A First Look at ASP. NET v. 2.0 2003
Authors: Homer A., Sussman D., Howard R.
Published year: 2004