• Choose a category
• All
• Classic-Fiction

enabled = "true"

duration = "-1"

location = ""

sqlDependency = ""

varyByCustom = ""

varyByControl = ""

varyByHeader = ""

varyByParam = ""

noStore = "false"/>

A database dependency is a special case of custom dependency that consists of the automatic invalidation of some cached data when the contents of the source database table changes. In ASP.NET, this feature is implemented through the SqlCacheDependency class. The section defines the settings used by the SqlCacheDependency class when using database caching and table-based polling against versions of Microsoft SQL Server equal or newer than version 7.

The pollTime attribute indicates (in milliseconds) the interval of the polling. In the preceding sample, any monitored table will be checked every second. Under the node, you find a reference to monitored databases. The name attribute is used only to name the dependency. The connectionStringName attribute points to an entry in the section of the web.config file and denotes the connection string to access the database. Which tables in the listed databases will really be monitored depends on the effects produced by another tool—aspnet_regsql.exe. I’ll return to this form of caching in Chapter 18,

Any values stored in the section have no effect when using SqlCacheDependency in conjunction with query notifications on SQL Server 2005 and newer versions.

The Section

The section specifies the error-handling policy for an ASP.NET application. By default, when an error occurs on a page, the local host sees the detailed ASP.NET error page, while remote clients are shown a custom error page or a generic page if no custom page is specified. This policy is controlled through the Mode attribute.

The Mode attribute can be set to On, Off, or RemoteOnly, which is the default. If it’s set to On, custom error pages are displayed both locally and remotely; if it’s set to Off, no special error-handling mechanism is active and all users receive the typical ASP.NET (yellow) error page with the original runtime’s or compiler’s error message and the stack trace.

Custom error pages can be specified in two ways. You can provide a generic error page as well as error-specific pages. A custom error page that is not error-specific can be set through the defaultRedirect attribute of the element. This setting is ignored if the mode is Off.

The section supports a repeatable child tag that is used to associate a custom page with a particular error code. You should note that only certain status codes are supported. Some error codes, such as 403, might come directly from IIS and never get to ASP.NET.

The tag has two optional attributes, redirect and statusCode. The redirect attribute points to the URL of the page, whereas the statusCode specifies the HTTP status code that will result in an error. If the custom mode is enabled, but no error-specific page is known, the default redirect is used. If the custom mode is enabled, but no custom page is specified, the ASP.NET generic error page is used.

Important

The aforementioned ASP.NET vulnerability discovered in September 2010 brought about a best practice as far ASP.NET security is concerned. You are now discouraged from using any element to return an error-specific page. By examining the error code, in fact, the attacker could learn enough to compromise your system. The recommended approach is setting the Mode attribute to On and to have all errors handled by the same error page, which is set through the defaultRedirect attribute.