.NET news » Search results

The Health Monitoring system in ASP.NET 2.0 is designed to monitor the health of a running ASP.NET application in a production environment. It works by recording event information to a specified log source. The .NET 2.0 Framework includes a variety of built-in events that can be used by the Health Monitoring system, including events for monitoring application re-starts and stops, unhandled exceptions, and failed authentication attempts, among others. The .NET Framework also include support for logging these events to the Windows event log, to a Microsoft SQL Server database, via WMI, in an email, and to the ASP.NET page tracing system.

In this article we will continue our exploration of the built-in events and log sources. In particular, we will look at the WebFailureAuditEvent event, which is raised when there is a security audit failure. We will also look at the SimpleMailWebEventProvider event provider, which, as its name implies, sends event information via email.

ASP.NET version 1.x did not include any built-in logging and notification system and therefore required a little bit of code or configuration effort from the developer. ASP.NET 2.0, however, provides built-in Health Monitoring facilities that make it a snap to configure a website to record events to the event log, a database, via WMI, in an email, or to the ASP.NET page tracing system. Moreover, the Health Monitoring system was created using the provider design pattern, making it possible to implement our own logging logic.

This is the start of a series that explores the ASP.NET 2.0 Health Monitoring system. In this article we will examine the basics of Health Monitoring and see how to setup Health Monitoring to log events to a SQL Server database..

Lookup and navigation screens initially seem like no-brainers, when compared to other parts of an application-yet by the time a developer has met all the user requirements and requests, he/she has expended much more time than expected. This issue of The Baker's Dozen will build a lookup Web page using ASP.NET 2.0, SQL Server 2005, and C# 2.0. The lookup and results page will contain optional lookup criteria and custom paging of the result set. The solution will utilize new language features in SQL 2005 for providing ranking numbers to correlate with custom paging, and new capabilities in .NET generics to pump the results of a stored procedure into a custom collection. Just like Mr. Mayagi taught Daniel the martial arts by doing exercises, the example in this article will demonstrate some common design patterns, such as factory creation patterns, using .NET generics. The article also subtly presents a general methodology for building database Web pages.

ASP.NET provides a couple of page-level state persistence mechanisms in ViewState and the new ControlState. While both mechanisms work, they both have some limitations in that they are not deterministic for the application developer-ViewState can be turned off and can be very bulky, and ControlState can only be set from within a control implementation. In this article I'll show another, more flexible state mechanism using a PreservePropertyControl that allows automatic persistence and restoration of field values automatically without requiring ViewState.

Working with big applications requires extending the Microsoft ASP.NET 2.0 Membership API to handle more detailed member records.In this article, I'll present one of the available techniques used to extend the Microsoft ASP.NET 2.0 Membership API to solve some of the limitations of that API.

ASP.NET 2.0's new cross-page postback capability gives developers three choices to choose between when transferring server processing from one page to another—and they're all useful in different scenarios.

Most Design Pattern documentation targets desktop applications or discusses pattern theory, but in this series you'll find a discussion and examples of patterns specifically targeted at ASP.NET.

Explains how to send e-mail from ASP.NET, including sending of simple e-mail, adding attachment, HTML e-mails and how to avoid potentially dangerous request errors.

Explore ways to reduce page load time, manage state efficiently, scale back on memory use, handle resources better, and improve data access in your ASP.NET applications.

Page state, commonly referred to as view state, is persisted in a hidden form field, by default. When a page is being rendered, any programmatic changes to a control's state is saved to the page's overall view state. During the rendering stage, this view state is serialized into a base-64 encoded hidden form field and sent down to the client's browser. On postback, the view state data is sent back to the web server, where it is deserialized and returned to the appropriate Web controls in control hierarchy so that they may re-establish their state as it was prior to the postback.

View state provides a slick way to remember state in a stateless client-server model and it happens underneath the covers without any extra effort from page developers. The downside of view state, however, is that in certain situations the view state can grow to be exceedingly large. A large view state requires a longer page download time since it bloats the total web page size and also affects the postback time, since the entire view state content must be posted back to the web server along with the other form fields.

It is possible, however, to persist view state to an alternate medium. Such customizations were possible in ASP.NET 1.x by overriding a couple of methods in the Page class. ASP.NET 2.0 makes customizing page state persistence easier as this logic is handled through a separate class. In this article we'll explore the built-in page state persistence options in ASP.NET 2.0, which includes the ability to persist page state to session state rather than through a hidden form field.