Erros mais frequentes no ASP.NET

Para quem está começando a desenvolver com ASP.NET e se depara com a tela amarela, já deve ficar horrorizado com a linguagem. Diferente das linguagens ultrapassadas, essa tela é muito útil para desvendar os problemas e, posteriormente, corrigí-los.


As telas de erro do ASP.NET mais comuns são aquelas nas quais são exibidas direto o erro para o usuário. Lembrando que já vimos em um post que isso demonstra vulnerabilidade do sistema mas que, a nível de homologação, é utilizável para identificar os problemas, análise da pilha e comportamento do mesmo.

Não vou explicar tudo sobre erros no ASP.NET senão teríamos um grande post de tudo o que ocasiona erros, mas para auxiliar os iniciantes, a Locaweb disponibilizou um tópico nas quais explica os erros mais comuns de programação bem como corrigí-los. Dêem uma lida para conferir... Veja aqui!

Utilizando mensagem de confirmação e executando código de acordo com o que foi clicado na mesma página

Não sei se o título ficou claro com o que eu queria dizer, mas vejamos a seguinte situação:
"Quero colocar uma mensagem de confirmação via code-behind onde irá ser emitida para o usuário e a depender do que ele escolher irá ser processado um certo trecho de código ou outro. Tipo o confirm do JavaScript, só que é executado pelo ASP.NET."

No Code Project tem várias formas de implementação e umas delas me chamou a atenção: o de Yavuz Kucukpetek. Usando AJAX é possível transformar um Panel nessa janela flutuante usando o ModalPopupExtender. Dei uma simplificada no código dele (já informei que não fiz, apenas ajustei) e você podem baixar o controle modificado aqui.

Depois que baixarem o controle, adicione no seu projeto. Vamos lá! Na página que deseja utilizar o controle, registre-o e coloque-o da seguinte forma:

<%@ Register Src="~/inc_ConfirmMessage.ascx" TagName="ConfirmacaoBox" TagPrefix="Thiago" %>


<Thiago:ConfirmacaoBox ID="ConfirmacaoBox" runat="server"></Thiago:ConfirmacaoBox>

No code-behind deverá ficar o seguinte:


    protected void Page_Load(object sender, EventArgs e)
    {
        ConfirmacaoBox.MsgBoxAnswered += Mensagem_Resposta;
    }



    public void Mensagem_Resposta(object sender, inc_ConfirmMessage.MsgBoxEventArgs e)
    {
        if (e.Answer == inc_ConfirmMessage.enmAnswer.OK)
        {
            // Se clicou em OK processa o que deseja
        }
        else
        {
            // Senão processa outra coisa
        }
    }



    protected void ExecutaProcesso_Click(object sender, EventArgs e)
    {
        ConfirmacaoBox.AddMessage("Deseja continuar o cálculo do processo na mesma página?", inc_ConfirmMessage.enmMessageType.Attention, true, true, "");
    }

Pronto! Apenas isso... Vamos às explicações. No Page_Load precisamos informar o método que irá gerenciar as decisões do usuário, por isso informamos o Mensagem_Resposta. Dentro dele irá conter os processos que irão ser executados a depender da escolha. O ExecutaProcesso_Click é o método executado quando clicamos no botão que irá disparar a pergunta.

"Ah Thiago, mas aí é só apenas uma confirmação. E se eu quiser várias interações?"

Simples, basta adicionar outra Caixa de Confirmação para a segunda etapa de decisões chamando-a dentro do processo de decisão da primeira e assim por diante.

Bloqueando apenas um acesso por vez em uma variável de aplicação

Toda aplicação web que trabalhamos raramente pensamos na quantidade de acessos que são realizados simultaneamente em um determinado trecho de código. Um exemplo clássico é uma variável de contador de acessos/visitantes. Armazenamos o valor inicialmente em uma variável de aplicação. Depois quando um usuário acessa, é incrementado em 1. Só que se ao mesmo tempo acessar dois ou mais usuários, eles podem capturar o mesmo valor ou valor defasado e colocar a contagem errada. Veja o exemplo abaixo:


Quando tivemos o acesso simultâneo\paralelo, o valor capturado da variável da aplicação foi colhido pelos dois usuários e o valor armazenado foi comprometido. Para isso devemos bloquear o acesso à variável de aplicação e permitir apenas um usuário por vez executar a soma. Nesse caso, pode-se utilizar o seguinte trecho:


        try
        {
            Application.Lock();
            lock (this)
            {
                // Trecho a ser executado que altera uma variável de aplicação ou bloco crítico
            }
            Application.UnLock();
        }
        catch
        {
            Application.UnLock();
        }


O Application.Lock() irá bloquear o acesso de outros usuários às variáveis de aplicação e depois o Application.UnLock() libera. O lock (this) permitirá apenas o acesso de um único usuário por vez no trecho de código crítico. A combinação dos dois métodos depende muito do que estiver fazendo. Cada caso tem seu respectivo uso. O simples uso do lock (this) pode resolver... Ele é muito usado para evitar deadlocks. No mais, só isso. Recomendo dar uma lida posteriormente nos artigos abaixo:

Diferenças entre Aplicações Compiladas e Não-Compiladas

Quando programávamos (ou programamos) com aquelas linguagens do tipo PHP ou ASP Clássico apenas pegávamos o que foi implementado e jogávamos no servidor web para uso. Com a inovação das tecnologias e tipos de linguagens (compiladas, interpretadas, híbridas) algumas dúvidas nos cercam quando estamos publicando um certo projeto. Nesse caso, falemos do ASP.NET para as versões acima da 2.0.

Antes de mais nada, o ASP.NET é compilado. Mesmo que você jogue os fontes no IIS ele é compilado na primeira vez que é acessado (e/ou alterado). Você não vê, mas por trás é feito isso. Para quem nunca compilou uma aplicação web, há diversas formas para uma dada finalidade. Geralmente é usada a função Publish Web Site (compila e publica).


Mas o que muitos perguntam é: existe diferença de desempenho? Não! Muitos dizem que há um pouco, mas já trabalhei com várias aplicações e não notei qualquer diferença. Li vários artigos por aí na net e não achei qualquer um que demonstrasse e/ou notasse diferença brusca de desempenho. Então, elaborei a seguinte tabelinha abaixo com um pequeno resumo. Se tiver mais, favor avisar-me que atualizo:


Compilada
Não-Compilada
 Desempenho
 Normal
Normal
 Código-fonte
 Protegido em DLL's
Visível 
 HTML
 Sem mudança
Sem mudança 
 Atualização\Correção
 Precisa compilar todo o projeto e publicá-lo (código-fonte) enquanto no design pode alterar normalmente
Pode alterar diretamente no problema (página)
 Primeiro Acesso
 Normal
Lento 

Óbvio que toda regra tem sua exceção, então a depender dos casos supra-citados pode haver pequenos detalhes que mudam uma coisinha ou outra mas nada de tão drástico (de acordo com a tabela - exemplo, na compilação FULL você não altera sequer o HTML). Se quiserem conhecer mais sobre os tipos de compilação (Full, Pré ou Sob-Demanda) visite os links da MSDN e de Dennes Torres.