Problemas com ASP.NET FileUpload

Em alguns cenários ao se trabalhar com o componente FileUpload no ASP.NET, revela-se uma caixa de pandora. Uma coisa importante ao se trabalhar com aplicações Web, é desabilitar as mensagens amigáveis de seu IE. Para fazer isso, basta acessar o menu Ferramentas> Opções da Internet> guia Avançadas> nas opções em Navegação, desmarque o checkbox Mostrar mensagens de erro HTTP amigáveis. e em seguida, clique em OK.

Voltando ao assunto, em alguns momentos, ao selecionar um arquivo para upload e executar qualquer ação/ evento que envolva um postback da página, a aplicação lança um erro. Existem muitas causas para este erro, mas a mais comum, é devido ao tamanho padrão para arquivos no controle.

Ou seja, para corrigir esta deficiência, basta definir no arquivo de configuração da aplicação (web.config) o seguinte nó:

<httpRuntime useFullyQualifiedRedirectUrl="true|false [para definir se haverá redirecionamento]" maxRequestLength="[tamanho máximo do arquivo em kbyes]" executionTimeout="120"/>

Na maioria dos cenários, esta pequena alteração costuma ser suficiente. Neste nó, outros parâmetros podem ser acrescentados para o controle de fila de requisições e das threads envolvidas.

Found a quote for which there is no matching quote

Debugando uma aplicação recentemente, me deparei com um "erro", no mínimo intrigante. No momento em que a aplicação realizava o acesso à base para realizar uma atualização, ocorria uma exceção com a seguinte descrição:

"Found a quote for which there is no matching quote."

Inicialmente fui até minha consulta para verificar se havia esquecido algum apóstrofo, para minha alegria/desespero, a consulta estava ok. Garimpando na internet, descobri que esse erro, poderia ocorrer caso eu tivesse me esquecido de um apóstrofo ou aspas, ou, se a primeira aspa/apóstrofo estivesse em uma linha diferente da aspa/apóstrofo final. Logo após a leitura, verifiquei que um dos parâmetros a ser persistido na base, possuía um "\n" (quebra de linha). Após remover a quebra de linha, o comando funcionou. Portanto, caso você se depare com este erro, vale a pena rever a documentação de seu sistema de gerenciamento do banco de dados, pois, dependendo do sistema, o tratamento de "novas linhas" pode ser uma configuração a ser desativada/ativada.

Introdução ao PSR(Problem Step Recorder)

O PSR (Problem Step Recorder), é uma ferramenta desenvolvida pela Microsoft para a exibição de cenários de erros. Por muitas vezes após a etapa de desenvolvimento de um sistema, na etapa de QA(Quality Assurance), alguns erros aparecem em cenários bem específicos, muitas vezes, não descobertos/percebidos ou até mesmo especificados no desenvolvimento. E neste momento, para facilitar a exibição do cenário, é que chega o PSR. Para acessar a ferramenta, pressione (Windows)+R e digite psr.exe.

Feito isso, será aberta a seguinte janela:

Ao clicar em iniciar gravação, pode-se minimizar a janela e todos os passos executados pelo usuário, serão detalhados. E quando digo todos, me refiro a TODOS! Todas as interações do usuário serão sumarizadas e printadas com a descrição da ação executada. Quando desejar parar, basta abrir a janela minimizada no início do tutorial e clicar em parar. Será gerado um arquivo zip com uma página em .mht com todos os passos para a simulação do erro. Espero que tenham gostado e que ajude!

Controlando Exceções

Em alguns momentos debugando algumas aplicações, nos deparamos com determinadas exceções que acabam nos atrapalhando, pois não é algo que se trate de um erro, mas sim um aviso da plataforma. Recentemente, me deparei com uma exception que me impedia de continar a depuração de uma rotina e a seguinte mensagem era exibida:

ContextSwitchDeadlock was detectedMessage: The CLR has been unable to transition from COM context 0x16a300 to COM context 0x16a020 for 60 seconds. The thread that owns the destination context/apartment is most likely either doing a non pumping wait or processing a very long running operation without pumping Windows messages. This situation generally has a negative performance impact and may even lead to the application becoming non responsive or memory usage accumulating continually over time. To avoid this problem, all single threaded apartment (STA) threads should use pumping wait primitives (such as CoWaitForMultipleHandles) and routinely pump messages during long running operations.

No Visual Studio 2010, há como controlar as exceptions a serem lançadas. No meu caso, esta mensagem tratava-se de um MDA (Managed Debugging Assistants). Para controlar algumas exceptions lançadas pela IDE, basta acessar o menu Debug->Exceptions > MDA e habilitar/desabilitar os check boxes.