Galhano //127.0.0.1

Quando ocorre um erro numa pagina. o ASP.NET envia informação sobre o erro para o cliente. Os erros são divididos em 4 categorias:

• Configuration errors: Occur when the syntax or structure of a Web.config file in the configuration hierarchy is incorrect.
• Parser errors: Occur when the ASP.NET syntax on a page is malformed.
• Compilation errors: Occur when statements in a page’s target language are incorrrect.
• Run-time errors: Occur during a page’s execution, even though the errors could not be detected at compile time.

By default, the information shown for a run-time error is the call stack (the chains of procedure calls leading up to the exception). If debug mode is enabled, ASP.NET displays the line number in source code where the run-time error originated. Debug mode is a valuable tool for debugging your application. You can enable debug mode at the page level, using the following directive:

>

Note: Running debug mode incurs a heavy performance penalty. Be sure to disable it before deploying your finished application.
Depending on the circumstances, you might want to handle application errors in different ways. For example, at development time you probably want to see the detailed error pages that ASP.NET provides to help you identify and fix problems. However, once an application is being served in a production environment, you probably do not want to display detailed errors to your customer clients. You can use ASP.NET to specify whether errors are shown to local clients, to remote clients, or to both. By default, errors are shown only to local clients (those clients on the same computer as the server). You can also specify a custom error page to redirect clients to if an error occurs.

---------
artigo completo aqui


											

Por padrão, todos os directório são herdados de um arquivo de configuração padrão de sistema chamado de machine.config, (localizado em: “WinNT\Microsoft.NET\Framework\Versão\CONFIG“).

O arquivo Global.asax opera de maneira semelhante as páginas *.aspx. Você utiliza o Global.asax para sincronizar qualquer evento exposto pela classe HttpApplication. Eventos quais veremos abaixo:

——————————-
——————————-

Imports System.Web

Imports System.Web.SessionState
Public Class Global

Inherits System.Web.HttpApplication
Sub Application_Start(ByVal sender As Object, ByVal e As EventArgs)

‘…

End Sub
Sub Session_Start(ByVal sender As Object, ByVal e As EventArgs)

‘…

End Sub
Sub Application_BeginRequest(ByVal sender As Object, ByVal e As EventArgs)

‘…

End Sub
Sub Application_AuthenticateRequest(ByVal sender As Object, ByVal e As EventArgs)

‘…

End Sub
Sub Application_Error(ByVal sender As Object, ByVal e As EventArgs)

‘…

End Sub
Sub Session_End(ByVal sender As Object, ByVal e As EventArgs)

‘…

End Sub
Sub Application_End(ByVal sender As Object, ByVal e As EventArgs)

‘…

End Sub

End Class

——————————-

Código 1 – O arquivo Global.asax.

• In-line code is code that is embedded directly within the ASP.NET page.
• Code-behind refers to code for your ASP.NET page that is contained within a separate class file. This allows a clean separation of your HTML from your presentation logic.

When we use Microsoft Visual Studio .NET to create ASP.NET Web Forms, code-behind pages are the default method. In addition, Visual Studio .NET automatically performs precompilation for us when we build our solution.

A little bit of background
Directives in ASP.NET control the settings and properties of page and user control compilers. They can be included anywhere on a page, although it is standard to place them at the beginning. Directives are used in both .aspx files (ASP.NET pages) and .ascx files (user control pages). ASP.NET pages actually support eight different directives.
* @ Page

* @ Control

* @ Import

* @ Implements

* @ Register

* @ Assembly

* @ OutputCache

* @ Reference
Page directives are the most commonly used directives, and are used to edit a wide variety of settings that control how the page parser and page compiler work. The following is a list of some of the more commonly used page directive attributes in ASP.NET.
@ Page language=”c#” Codebehind=”WebForm1.aspx.cs”

AutoEventWireup=”false” Inherits=”TestWebApp.WebForm1″

• Language indicates the language in which the inline script code within the ASP.NET page is written (the code between tags). The value of this attribute can be C#, VB, or JS.

• Codebehind indicates the name of the file being used as the code supporting this ASP.NET page. This file should reflect the Language setting; that is, if the language being used is C#, the CodeBehind file should have a .cs extension and be written in C#.

• Inherits indicates a qualified class from which this ASP.NET page should inherit. Generally, this will be the name of the class described in the code-behind file.

• AutoEventWireup is a Boolean attribute that indicates whether the ASP.NET pages events are auto-wired.

Note: In the above case, ASP.NET compiles the code-behind page on the fly. We have to note that this compilation step only occurs when the code-behind file is updated. Whether the file has been updated or not, well this is detected through a timestamp change.

To get to the Real Thing
The AutoEventWireup attribute may have a value of true or false. When an ASP.NET Web Application is created by using Microsoft Visual Studio .NET, the value of the AutoEventWireup attribute is set as false.
We can specify the default value of the AutoEventWireup attribute in the following locations:

• The Machine.config file.
• The Web.config file.
• Individual Web Forms (.aspx files).
• Web User Controls (.ascx files)

The value of the AutoEventWireup attribute can be declared in the

section in the Machine.config file or the Web.config file.