Tips and Tricks
What's New in 2.0
- Cross Page Posting - ASP.NET 2.0 allows you to post back from one page to another and you can obtain the source page values from the target page.
- Wizard Control - The wizard control allows you to easily add multi-step form entry scenarios to your pages.
- Validation Groups - Validation groups allow multiple forms on a page to be separately validated.
- Focus API - The Focus API enables you to set focus to any control on the page, specify default buttons to submit for input controls, and more.
- Compilation Build Providers - ASP.NET 2.0 includes support for compiling declarative file formats when they are placed in the App_Code directory.
- No Compile Pages - Pages in ASP.NET 2.0 can be excluded from the compilation process, to be interpreted at runtime instead.
- Securing Non-ASP.NET content - Under IIS 6, you can easily secure non-ASP.NET files such as static images or classic ASP pages from within an ASP.NET application.
- Client-Script Features - ASP.NET 2.0 includes several new features that take advantage of client-side script.
This section describes tips and tricks for using several new features in ASP.NET 2.0.
Cross Page PostBack
By default, button controls in ASP.NET pages post back to the same page that contains the button,
where you can write an event handler for the post. In most cases this is the desired behavior, but
occassionaly you will also want to be able to post to another page in your application. The
Server.Transfer method can be used to move between pages, however the URL doesn't change.
Instead, the cross page posting feature in ASP.NET 2.0 allows you to fire a normal postback to a different page in
the application. In the target page, you can then access the values of server controls in the source page that initiated the post back.
To use cross page posting, you can set the PostBackUrl property of a Button, LinkButton or ImageButton control, which specifies the target
page. In the target page, you can then access the PreviousPage property to retrieve values from the source page.
By default, the PreviousPage property is of type Page, so you must access controls using
the FindControl method. You can also enable strongly-typed access to the source page by setting the
@PreviousPageType directive in the target page to the virtual path or Type name of the source page.
Note that if you intend for multiple pages to post to a single target page, you cannot use the
strongly-typed accessor (leave the PreviousPage directive unset).
VB Cross Page PostBack
Cross page posting works by the following technique:
Because Page 1 will execute (up to LoadComplete) in response to a cross-page post,
it is sometimes necessary to special-case code in the page to only execute when the request
is not a cross-page post, but a normal request to Page 1 instead. You may use the IsCrossPagePostBack
property in Page 1 to handle this situation.
- Cross page posting sets action of the form in Page 1
- When the Button is clicked, the post goes from Page 1 to Page 2
- Page 2 retains viewstate from Page 1
- When PreviousPage accessed, viewstate is re-populated to an instance of Page 1
- Page 1 then executes up to its LoadComplete phase (excludes rendering)
- At this point, Page 2 may access the values of controls in Page 1
If Not Page.IsCrossPagePostBack Then
' handle a normal request
You can also post back to another application, however the PreviousPage property is null in this case.
You can also transfer in code, while still preserving viewstate through the PreviousPage property using
The Wizard control is used to create a multi-step form entry process in a web page.
To specify the individual steps , place a WizardStep object for each entry between the opening and closing tags of the WizardSteps element of the Wizard control.
There are many benefits to the Wizard control:
- Easily enable multi-step forms and data collection
- Handles all aspects of navigation, linear or non-linear
- Enables commit-at-finish or commit-as-you-go (AllowReturn=false)
- Controls automatically retain viewstate across posts to different steps
- Can use built-in UI, or customize through properties or templates
VB Wizard Control
You can use the ValidationGroup property when you want to perform separate validation scenarios on the same page.
Set the group name on validator controls and on the button or other postback control that causes validation. This is useful with Wizard control, MultiView or data controls (for editing scenarios).
To enable validation groups, set this property to the same value for all validators that should belong to a common group. On a Button control in the form with CausesValidation
set to true, you also set the ValidationGroup property to the name of the group that should be validated when the Button is clicked.
By default all validators are in the "" group (default group), for backward compatibility. The
Page object also exposes a GetValidators("group") method and Validate("group") method for
retrieving a collection of validators in a specific group.
Page.IsValid reflects validity of all controls (cumulative) that have had Validate called.
The example below demonstrates the ValidationGroup property. To view the behavior, click the first (Search) button in the
page, then click the second button on the page. Notice that a different set of validators fires for each click.
VB Validation Groups
Focus API and DefaultButton
The Focus API allows you to declaratively or programmatically set focus to specific controls on the form. You can use the Page.SetFocus method to pass the ID of a control
that should receive focus or you can call the Focus method on the control directly.
You can also set the DefaultFocus property of the Form element to the ID of a control that should receive focus when the page is first loaded.
Similar to DefaultFocus, you can set the DefaultButton property of the Form element to the ID of a Button control that should submit when the Enter
key is pressed inside of any input control on the form. If your page should have different default buttons depending on the input control that has current focus,
you can wrap specific input controls in a Panel control and set the DefaultButton property of the Panel instead. Any input control in the Panel will use
the Panel's DefaultButton property to submit the form when the Enter key is pressed from within the input control.
A validation feature that depends on the Focus API is SetFocusOnError which is set on validator controls to cause the first invalid control to receive focus.
The following example shows the Focus API, DefaultButton, DefaultFocus, and SetFocusOnError features in use on a single form.
VB Focus API, DefaultButton, DefaultFocus, and SetFocusOnError
For composite controls, the Focus method sets focus to the first
focusable control in the composite control rendering by default, but individual controls can override this behavior to set focus to another element.
This example shows the focus given to the first input control in a DetailsView when the Focus method is
called when the DetailsView is in edit mode.
VB DetailsView Focus
Compilation Build Providers
A compilation build provider in ASP.NET 2.0 is a type that is registered to "compile" or "build" a declarative
file format into something that can be used from your pages. A build provider is registered in configuration and is associated to a specific
file extension. When files having this extension are placed into the App_Code directory, ASP.NET invokes the
registered build provider to compile the file. ASP.NET 2.0 includes support for several compilation
build providers out-of-the-box or you can also create and register your own types (refer to the
section for more information. In addition to standard class files in various languages, the following declarative
types can be automatically compiled in ASP.NET:
- .wsdl - builds a Web Service proxy object
- .resx - builds a resources file that can be used for localization
- .xsd - builds a strongly-typed DataSet object
No Compile Pages
No Compile Pages enables improved scaling for large sites with 1000s of pages,
as windows has limit on number of DLLs loaded into an app and perf degrades as you hit this limit.
<%@ Page CompilationMode="Auto" %> directive to compile conditionally to obtain the
scaling benefits without limitations on code. You can also set CompilationMode to "Never" to prevent the page from
ever being compiled. You can set this property on the
<pages/> section in Web.config
to apply to all pages in an application.
A no-compile page will throw an error when it contains user code. However, you may still use
declarative ASP.NET syntax such as data bindings (
<%# Eval %> and
<%#Bind %> only) and
expressions, such as
<%$ ConnectionStrings:Pubs %>.
VB NoCompile page
The CompilationMode property only applies to pages,
but you can still use types from within the Code directory (for example base classes for pages). If
you prefer for no-compile pages to be excluded access to compiled types from the Code directory,
lock this directory down in configuration.
VB NoCompile page with a base class
A complementary feature is the pre-compile tool, aspnet_compiler.exe, which allows you to pre-compile an
entire site using a command-line tool, to protect your intellectual property (code) in pages and enable
deployment without an initial compilation hit.
Securing Non-ASP.NET Files
ASP.NET handles requests for file extensions that are normally associated with ASP.NET, while IIS handles requests for all other file extensions. By default this
means common file extensions such as .aspx and .asmx are processed by ASP.NET. This processing includes authentication and authorization to ASP.NET files. Sometimes
though, a developer wants non-ASP.NET resources to be processed by ASP.NET. One reason for processing non-ASP.NET files through ASP.NET is to allow ASP.NET
authentication and authorization to control access to these types of files.
The combination of IIS6 on Windows Server 2003 and ASP.NET 2.0 provides the most flexibility for running the ASP.NET pipeline as part of processing a request for a
non-ASP.NET resource. IIS6 includes support that allows ASP.NET 2.0 to perform authentication and authorization steps, and to then hand off the remainder of the
processing of a non-ASP.NET resource back to IIS6. For example, it is possible to authenticate access to an ASP page using ASP.NET forms authentication, authorize access
with ASP.NET's Url authorization and still allow the ASP ISAPI extension (asp.dll) to execute the ASP page. This support is possible because IIS6 introduced a new server
support function for ISAPI extensions:
Assume that a directory structure contains a mix of both ASP and ASP.NET files. The ASP.NET pages are used to log a user in with forms authentication, while the
ASP pages represent the rest of the application. Using the IIS6 MMC, right-click on directory and create an application (this is the same step that is necessary
when setting up a standard ASP.NET application). After an application has been created, click on the Configuration button that is located on the Directory
property page. This will cause the Application Configuration dialog to be displayed. New to IIS6 is a feature called wildcard application mapping. The
bottom of the Application Configuration dialog allows you to configure this feature.
First determine the path for the ASP.NET ISAPI extension that processes ASP.NET files such as .aspx files. You can find this path by looking at the
extensions that are listed in the Application Extensions list shown in the top half of the Application Configuration dialog. Click on the row in the list
that maps the .aspx extension, and select the Edit button. In the dialog that pops up, highlight the text in the Executable textbox and copy it to the clipboard. Then cancel out
of the dialog.
Next, click the Insert button that is in the bottom half of the Application Configuration dialog. A dialog box titled Add/Edit Application Extension
Mapping will be displayed. In the Executable text box, enter the path to the ASP.NET ISAPI extension that you copied to the clipboard earlier. The end result
should look something like the screenshot below.
Click OK to close out all of the dialogs. Now whenever a request is made for any file, the request will first be processed by ASP.NET. If the web.config for your
ASP.NET application has enabled forms authentication, an unauthenticated request for a .asp file will first trigger a redirect to the login page configured for forms
authentication. After a user has successfully logged in, they will be redirected back to the original .asp page. When the now-authenticated user requests the .asp page,
ASP.NET will first run through the
FormsAuthenticationModule to verify that the forms authentication cookie exists and is still valid. If this check passes,
ASP.NET will hand processing of the .asp page back to IIS6, at which point IIS6 will pass the request on to the ISAPI extension that normally process .asp pages. In this
case the extension is asp.dll and the ASP page will then run to completion. The reason ASP.NET will pass the request back to IIS6 is that non-ASP.NET resources will
fall through the list of configured
<httpHandlers> to the following entry:
<add path="*" verb="GET,HEAD,POST" type="System.Web.DefaultHttpHandler" validate="True" />
DefaultHttpHandler is responsible for handing requests back to IIS6 for further processing.
A similar technique with some constraints is available on IIS5 and IIS5.1. These versions of IIS require that for each file extension that a developer wants processed by
ASP.NET, an explicit mapping to the ASP.NET ISAPI extension must be added to the Application Extensions list described earlier. The second constraint is that
IIS 5.x does not allow a request to be passed back from ASP.NET to IIS 5.x. As a result, only static files requested using the GET verb can effectively be protected by
ASP.NET. After the first half of the ASP.NET pipeline executes (which includes authentication and authorization), ASP.NET will process the resource using an
StaticFileHandler rather than attempting to pass the request back to IIS 5.x. Attempts to process the POST verb, or to request .asp files will
result in a 405 (invalid method) or 403 error (forbidden: access denied) respectively.
ASP.NET 2.0 includes a number of features that rely on client-side script in the browser.
For example, the OnClientClick property of Button control allows you to programmatically run client-side script when
the Button is clicked. The Button renders the client-side
VB ClientClick Event
There are cases where an application requires the position of the page in the browser to remain
after post-back to the server. For example, if data entry causes post-back in a large page, the
end-user would be required to scroll the page to the position that they were editing at in order
to continue. Page developers can simply mark their form to maintain scroll position by setting
the MaintainScrollPositionOnPostBack property to true in the
or by setting this in Web.config to apply to all pages in an application.
VB Maintain Scroll Position
An exciting new feature for controls are Client-side CallBacks, which allow a control to execute an
out-of-band request back to the server to obtain additional data, without posting the entire page. This feature
relies on browser support for callback handling (usually through XMLHTTP), as specified by the
property in browser capabilities.
The TreeView control takes advantage of this feature to enable populating tree nodes on-demand
when a parent node is expanded on the client. GridView and DetailsView also take advantage of this feature
to implement paging and sorting when EnableSortingAndPagingCallbacks is set to true. A control registers itself
as being able to receive callback events by implementing the
This interface allows the page to invoke registered delegates for returning callback data to the client.
There are two methods of the ICallBackHandler interface,
RaiseCallbackEvent accepts an argument for context (args passed from the client), which can be used to process the event.
GetCallbackResult returns a String that represents the data to return to the client. The reason this interface is separated
into two methods is to allow for asynchronous processing, for example to retrieve data from a data source control.
The control then registers a client-side callback function that knows how to create the arguments to pass to the server-side delegate, and an error handling function to
be invoked when an error in callback processing occurs. Finally, the control
emits references to callback events using
An example below demonstrates the use of client-side callbacks to implement a cascading DropDownList scenario.
In this case, the Page itself implements the ICallbackEventHandler interface, for demonstration purposes.
VB CallBack Event Handlers