Se você alguma vez se deparar com esse erro, normalmente pode resolvê-lo muito rapidamente, mas é provável que ele apareça novamente. O InvalidCastException, “Não é possível lançar o objeto do tipo‘ ASP.type ’para‘ ASP.Type ’” é um erro de ocorrência extremamente aleatório. É tão difícil apontar que mesmo os programadores de crack da Microsoft têm apenas um HotFix não publicado disponível. Você precisa ligar para obter o HotFix. Parece haver algumas maneiras comuns de corrigir esse erro, mas nenhuma é razoável para muitas situações.

De acordo com o artigo da KnowledgeBase, isso pode ocorrer em quatro cenários, o meu foi causado pelo problema nº 2.

  • O aplicativo da Web usa uma página mestra, um controle de usuário ou páginas que fazem referência umas às outras.
  • A página mestra, o controle de usuário ou as páginas são compiladas em lote em um montagem única.
  • Uma das dependências em lote é alterada e causa uma recompilação.
  • Uma chamada dinâmica para carregar uma referência é feita, como uma chamada para o método LoadControl.

Primeiro, o que é esse erro e como você o obtém. Bem, eu não tenho certeza de como’obter’o erro; Só sei que ocorre aleatoriamente na natureza do ASP.NET (veja o canal de descoberta). De qualquer forma, às vezes recebo este erro quando estou usando uma MasterPage que é herdada de uma classe MasterPage personalizada que criei e que é herdada diretamente da própria MasterPage. Portanto, se você olhar para a hierarquia, verá MasterPage-> MyBaseMasterPage-> MyActualMasterPage. O erro seria semelhante a:

Não é possível lançar o objeto do tipo’ASP.MyActualMasterPage’para digitar’MyActualMasterPage’

Um exemplo do código que irá causar este erro seria semelhante ao seguinte:

Protegido

mrmpc

As

MyRealMasterPageClass

mrmpc=

CType

(Page.Master, MyRealMasterPageClass)

‘Aqui é onde o erro seria indicado

99,99% das vezes você nunca verá esse erro ocorrer. Mas se você fizer isso, parece haver uma ordem que você precisa cumprir para combater o problema. A pior solução é quebrar sua arquitetura e replicar o código comum na classe para cada classe MasterPage que você criar, por favor, não faça isso ou alguém pode denunciá-lo a WorseThanFailure.com um dia. A primeira etapa é modificar o arquivo web.config para desativar a Compilação em lote. Para fazer isso, localize a tag de compilação em seu arquivo web.config e defina batch=”false”.

O atributo batch indica se a compilação batch está ativada, aqui está a definição do atributo de acordo com a documentação:

Se True, elimina o atraso causado pela compilação necessária ao acessar um arquivo para a primeira vez. Quando este atributo é definido como True, o ASP.NET pré-compila todos os arquivos não compilados em um modo de lote, o que causa um atraso ainda maior na primeira vez em que os arquivos são compilados. No entanto, após esse atraso inicial, o atraso de compilação é eliminado no acesso subsequente ao arquivo.

O motivo pelo qual você deseja desligar o compilador em lote é porque é aí que reside o bug. Portanto, ao desligar o compilador de lote, você está contornando o problema, mas pode estar criando uma pequena queda no desempenho. Descobri que isso resolveu meu problema na configuração do servidor de desenvolvimento, mas não na configuração de produção.

A próxima etapa é entrar em contato com o Suporte da Microsoft por meio do artigo da Base de conhecimento sobre o HotFix. Fiz isso e até ganhei um segundo HotFix depois que o primeiro não funcionou. Não tivemos a chance de aplicar o segundo HotFix ao servidor de produção porque resolvi o problema para nós um pouco antes de ele ser lançado.

Antes de chegar à maneira como resolvi o problema, quero para oferecer mais algumas dicas sobre o que experimentei. Primeiro, parece haver um sintoma de que pode ser um problema dentro do Visual Studio. De vez em quando, minhas referências às minhas classes MasterPage são marcadas como um erro ou que a classe não existe. Eu encontrei uma maneira de eliminar o erro falsamente relatado: fechar o Visual Studio e limpar os arquivos temporários associados ao site na minha estação de trabalho. Esses arquivos estão localizados no diretório C: \% SystemDir% \ Microsoft.NET \ Framework \ v2.0.50727 \ Temporary ASP.NET Files ”. Você verá um subdiretório para cada site em que trabalhou desde a última vez que limpou a estrutura. Eu geralmente excluo todas as pastas neste diretório e começo do zero.

Outro comportamento estranho que percebi foi clicar com o botão direito do mouse na classe MasterPage que causou o erro e escolher ir para Definição me levou ao Visualizador de classes e uma referência a um objeto no diretório temporário mencionado acima. Não tenho ideia do que causa esse comportamento, a classe definitivamente existe.

Este é outro problema muito estranho na recriação do erro. Eu poderia visitar o site de minha estação de trabalho e carregar várias páginas repetidamente por um longo período de tempo. Na verdade, eu realmente executei um script automatizado por cerca de uma hora em um ponto sem nenhum erro gerado. Eu poderia, então, abrir um novo navegador e, de repente, o erro de fundição apareceria de forma desagradável. Já que não tenho o privilégio de saber como o motor ASP.NET realmente funciona, não tenho ideia de por que gerei o que fiz.

O último sintoma é que parece que o erro irá corrige-se magicamente após um ou dois minutos e também não é consistente entre as páginas. Por exemplo, se eu puder carregar algumas páginas que usam MyMasterPage e todas elas tiverem o mesmo código para lançar uma referência à MyMasterPageClass sem causar o erro. Posso chegar à quarta página e o erro é lançado. Posso voltar a outras páginas que usam essa classe e têm a linha e funcionam bem. Então posso voltar para a página que gerou o erro e ele pode ou não estar lá novamente, normalmente acho que se eu der um minuto ou mais, o erro irá embora. É difícil dizer que isso acontecerá em todas as situações. Minha configuração envolveu um web farm de quatro servidores, então posso ter acabado de ser roteado para um novo servidor que não causou o erro.

Agora, como resolvi meu problema. Acontece que eu encontrei alguns bons artigos sobre pré-compilar aplicativos ASP.NET 2.0 a poucos dias antes de ocorrerem esses erros. Como os erros parecem ser causados ​​pelo compilador em lote, achei que valeria a pena tentar pré-compilar o site para que o compilador em lote fosse completamente ignorado. Funcionou e agora podemos prosseguir. Estou pensando em abandonar outra entrada na pré-compilação porque acho que essa pode ser uma das melhores opções que uma equipe ASP.NET tem para um aplicativo de desempenho extremamente alto também.

Compartilhe este artigo com seus amigos!

Source link

Categories: Wordpress