Throughout this chapter we have used the @Page directive to control the default language, code-behind class, and implicit assembly compilation of our .aspx files. In addition to the @Page directive, several other directives are available for use in .aspx files, as shown in Table 1-1. Because every .aspx file is compiled into a class, it is important to have control over that compilation, just as you would via compiler switches if you were compiling a class yourself. These directives give you control over many options that affect the compilation and running of your page. Table 1-1. .aspx File Directives
The @Assembly directive provides a way for .aspx files to reference assemblies that are deployed in the global assembly cache or, using the src attribute, to reference a source file that is compiled and referenced implicitly when the page is referenced. The @Import directive serves the same purpose as the using keyword in C#, which is to implicitly reference types within a specified namespace. The @Implements directive gives you the ability to implement an additional interface in your Page -derived class, and the @Reference directive provides a mechanism for referencing the generated assemblies of other pages or user controls. To see an example of when you might use some of these directives, suppose we decide to deploy the TempConverter class in the global assembly cache so that all the applications on our machine can access its functionality. We also wrap it in a namespace to ensure that there is no clash with other components in our system, and sign it with a public/private key pair. Listing 1-14 shows the source file for our TempConverter component. Listing 1-14 Source File for TempConverter Component// File: TempConverter.cs using System; using System.Reflection; [assembly : AssemblyKeyFile("pubpriv.snk")] [assembly : AssemblyVersion("1.0.0.0")] namespace EssentialAspDotNet.Architecture { public class TempConverter { static public double FahrenheitToCentigrade(double val) { return ((val-32)/9)*5; } static public double CentigradeToFahrenheit(double val) { return (val*9)/5+32; } } } To reference the TempConverter in one of our pages, we need to reference the TempConverter assembly deployed in the GAC, and we need to fully scope the reference to the class with the proper namespace. To reference a GAC-deployed assembly, we use the @Assembly directive, and to implicitly reference the namespace in which the TempConverter class is defined, we use the @Import directive. A sample page using these directives to work with the TempConverter component is shown in Listing 1-15. Note that to successfully reference a GAC-deployed assembly, you must use the full four-part name of the assembly, including the short name, the version, the culture, and the public key token. Listing 1-15 Sample .aspx Page Using the TempConverter Component<! TempConverter.aspx > <%@ Page Language='C#' %> <%@ Assembly Name="TempConverter, Version=1.0.0.0, Culture=Neutral,PublicKeyToken=a3494cd4f38077bf" %> <%@ Import Namespace="EssentialAspDotNet.Architecture" %> <html> <body> <h2>32deg F = <%=TempConverter.FahrenheitToCentigrade(32)%> deg C</h2> </body> </html> The @Page directive has by far the most attributes of any of the directives. Some of these attributes have been brought forward from similar directives in traditional ASP pages, while many are new and unique to ASP.NET. Table 1-2 shows the various @Page directive attributes available, along with their possible values and a description of the attribute usage. The underlined value is the default that will be used if the attribute is left off the @Page directive. Table 1-2. @Page Directive Attributes
One of the attributes that may be of particular interest to developers migrating existing ASP applications is the AspCompat attribute. This attribute changes the way a page interacts with COM objects. If you are using COM objects that were written in the single-threaded apartment (STA) model (all VB COM objects fall into this category), there will be additional overhead in invoking methods on that object because ASP.NET pages will by default run in the multithreaded apartment (MTA) when accessing COM objects. If you find that you are writing a page that has a significant number of method calls to STA-based COM objects, you should consider setting the AspCompat attribute to true to improve the efficiency of communication with those objects. Be aware that enabling this attribute also creates COM wrappers on top of the Request and Response objects enabled with ObjectContext , adding some overhead to interacting with these classes. The ClassName attribute lets you decide the name of your Page -derived class, instead of accepting the default name, which is derived from the .aspx file name. With the CompilerOptions attribute you can specify any additional compiler switches you would like to include when your page is compiled. For example, Listing 1-16 shows a page that has requested that warnings be treated as errors when this page is compiled and that the page be compiled with overflow checking enabled for arithmetic operations. Listing 1-16 Specifying Additional Compiler Options for a Page<%@ Page Language='C#' CompilerOptions="/warnaserror+ /checked+" %> |