.NET news » ASP.NET

Compilation and deployment are key features that ASP.NET developers should understand quite well. Find out how the process works and what options are available to compile and deploy your applications effectively.

When a user clicks a submit button in a form, their browser makes a request back to the web server for the specified URL. On the web server, the user's input is processed and some action is taken based on the input. A database record might be added, an email might be sent, and so on. One potential issue that can arise is if a user submits a form, but there is a delay in getting back a response from the server. A user may think that the button click didn't "take", so they click it again. This can lead to two form submissions, resulting in two database records being added, two emails being sent, or whatever. Two possible methods to prevent it described in the atricle.

The XmlDataSource control makes accessing, filtering, and transforming XML data a simple, code-free process. Additionally, the XPath() and XPathSelect() databinding methods added to ASP.NET 2.0 make displaying particular XML values or binding entire XML nodesets just as easy. And the XML data accessed can be from a local file or automatically downloaded from a specified URL. In this article we will examine how to use the XmlDataSource control and the XPath() and XPathSelect() databinding methods, displaying the results in a variety of data Web controls..

Explains how to use caching to improve performance in ASP.NET applications.

ASP.NET Applications speed optimizations regarding to use of page and server controls, web application settings and best coding practices

Overview of the steps necessary to cache Pages or application data based on the new ASP.NET 2.0 SqlCacheDependency features.

ASP.NET provides a variety of validation Web controls that can be used to validate a user's form field inputs. Unfortunately, the validation Web controls do not work with the CheckBox or CheckBoxList Web controls. If you set a validation control's ControlToValidate property to the ID of a CheckBox or CheckBoxList, the page will throw an HttpException, stating: "Control 'controlID' referenced by the ControlToValidate property of 'validationControlID' cannot be validated."

There may be times, however, when you need to provide validation for a CheckBox or CheckBoxList. Many Web pages with Terms of Service include a CheckBox titled "I agree to the above terms" that must be checked before continuing. Likewise, a Web Form may contain a set of options in the form of a CheckBoxList. Perhaps the user is required to check at least one of these options before continuing.

In this article we'll create two custom server controls, CheckBoxValidator and CheckBoxListValidator. The download at the end of this article includes both the entire source code and a compiled assembly that you can drop into your ASP.NET 2.0 web applications..

Developers often concentrate on writing secure code but leave security vulnerabilities in application configuration files. Discover the most common configuration security problems—and how to avoid them.

Visual Basic .NET and Visual Basic 6.0 developers get an introduction to building Web applications with ASP.NET 2.0, as well as the major differences between developing desktop and Web applications.

In .NET applications, an illegal operation - an invalid cast, attempting to reference a null value, trying to connect to a database that's been taken offline, and so on - raises an exception. Exceptions can be caught and handled directly in code through the use of Try / Catch blocks. For ASP.NET applications, if the exception is not handled in code, it bubbles up to the ASP.NET runtime, which raises an HttpUnhandledException. By default, unhandled exceptions result in a page that displays the text, "Runtime Error" with instructions for developers on how to display exception details (see the screen shot to the right). This "Runtime Error" error page is what is seen by external visitors; if you visit your site through localhost and an unhandled exception occurs, the default error page includes the type and details of the exception thrown.

End users will no doubt find the "Runtime Error" page to be intimidating and confusing - do you think the average computer user knows what "Runtime" means? All the user knows is that something went horribly wrong. They might fear that their data or progress has been lost and that they are responsible for the error. Ironically, the person who does care that an unhandled exception has occurred - the developer - is left out of the loop unless the end user takes the time to email the developer the details of the error (what page it happened on, the steps the user had performed that caused the error, and so on)..