Aplicativo da Web do ASP.NET não consegue encontrar uma montagem

StackOverflow https://stackoverflow.com/questions/2542114

Pergunta

Eu implantei um aplicativo da Web do ASP.NET na noite passada e, quando acordei esta manhã, era muito lento e, ocasionalmente, apenas jogava um erro de 'serviço indisponível'.

Eu verifiquei o visualizador de eventos e ele estava preenchido com esses erros:

Uma exceção não atendida ocorreu e o processo foi encerrado.

Exceção: System.Runtime.Serialization.SerializationException

Mensagem: Não é possível encontrar a Assembléia 'Monotorrent, versão = 0.80.0.0, cultura = neutro, publicKeyToken = null'

Estou intrigado, pois estava funcionando perfeitamente quando o implantei (é necessário que o monotorrent recupere o número de semeadores/sanguessadores para uma certa torrente fora do rastreador - isso estava funcionando bem), mas não está mais funcionando e sempre que o código que usa monoterente se envolve, o processo do trabalhador simplesmente trava.

Monotorrent.dll está no / bin / diretório.

Atualização 6/4/10: Compilei o código -fonte monotorrent com o restante do meu aplicativo da web, mas ele ainda trava sempre que ele usa o monotorrent. No entanto, agora diz que é Unable to find assembly 'OpenPeer, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null. Aqui, o OpenPeer é o nome da montagem do aplicativo da web.

Nenhuma solução correta

Outras dicas

Isso pode acontecer nessas circunstâncias:

O aplicativo ASP.NET cria um tópico de fundo, que lança uma exceção não capturada. Parece que o ASP.NET pega a exceção e deseja registrá -lo no log de eventos. Para fazer isso, ele envia essa exceção do domínio do aplicativo do aplicativo da Web para seu próprio domínio de aplicativo (o padrão do processo W3WP). Isso precisa de uma serialização/desserialização da exceção.

Se a exceção for personalizada (ou seja, definida pelo aplicativo da web), ela não pode ser desapontada no domínio principal do aplicativo do ASP.NET porque a assembléia que define a exceção está normalmente no diretório da lixeira do aplicativo da web, não onde o w3wp.exe está (C: Windows System32 inetsrv). Isso causa uma exceção de serialização e falhas de W3WP.

Existem maneiras possíveis de corrigir o problema (em uma ordem de preferência muito subjetiva):

  1. Copie a DLL ausente em C: Windows System32 inetsrv
  2. Instale a DLL ausente no GAC
  3. Remova a causa da exceção (mais difícil de fazer do que dizer, como dizemos em francês)
  4. Pegue todas as exceções do encadeamento de segundo plano e faça o registro você mesmo.

Notas:

  • Se o WCF for usado e a exceção não capturada é a FaultException, o WCF o engole e não há falha
  • Se a exceção não capturada estiver no segmento da solicitação da web, há uma tela amarela de morte, não esta exceção de serialização
  • Realmente parece um bug no asp.net
  • O exposto acima é realmente um resumo das minhas investigações sobre essa edição ontem e são apenas uma teoria. Testei as correções 1 e 4, além de usar o FagressException.

Tentar Limpando os arquivos de temperatura do ASP.NET. Ele já resolveu alguns problemas estranhos antes para mim.

Por outro lado, Logging de fusão pode lançar um pouco de luz.

ATUALIZAÇÃO: @Charlie - Não tenho certeza do que fazer com esses logs ... parece que o log com falha é de um aplicativo diferente. Observe que o AppBase está definido como "Arquivo: /// c:/windows/system32/inetsrv/" e appName é w3wp.exe.

Tenho certeza de que o visualizador de eventos deve mostrar o ID do aplicativo: LM/W3SVC/#/raiz se também fosse o aplicativo padrão. Neste ponto, tudo o que tenho são palpites aleatórios.

  1. Percebo que você está executando x64 ... monotorrent talvez requer x86?
  2. Você verificou duas vezes se o diretório é um aplicativo do IIS e está configurado para a versão correta do ASP.NET?
  3. Existe algum outro aplicativo que use o monotorrent neste servidor? Talvez um serviço WCF ou algo assim? Não tenho certeza de onde a serialização está acontecendo ....
  4. Tente conectar o Evento AssemblyResolve e carregando -o manualmente.
  5. Você pode reproduzir em uma máquina de desenvolvimento? Caso contrário, talvez seja uma instalação de FX Borked. Desinstalar e reinstalar.
  6. A reinicialização, reciclagem ou interrupção/partida do AppPool corrige o problema temporariamente ou faz com que o problema apareça?

Você pode digitar seu texto de captura de tela também, para que você tenha um pouco de amor do Google ....

Aqui estão algumas coisas que você pode tentar ..

1.) FLOW. Reinicie o IIS e Pool de aplicativos de reciclagem.

2.) Certifique-se de que sua aplicação na web esteja funcionando Plena confiança Se realmente precisa de plena confiança.

3.) Pegue a montagem, tente usá -lo em outro aplicativo ASP.NET e Execute o aplicativo de teste em um servidor separado. Isso pode ajudá -lo a diagnosticar o problema. Tente também executar o aplicativo Test ASP.NET no mesmo servidor, mas no pool de aplicativos separado.

4.) Certifique -se de que o O site do IIS do seu aplicativo está em execução na conta de usuário com os privilégios de segurança necessários. Tente executar o aplicativo em AdministrAToTR como usuário.

Edit-1

5.) Verifique também se a versão de montagem é a mesma mencionada no web.config. Se houver uma incompatibilidade de versão, você pode fazer Redirecionamento de montagem em web.config.

6.) Experimente também o Registaing da montagem no GAC e veja se ele carrega corretamente.

Edit-2

7.) Tente reconfígar o suporte do ASP.NET no servidor ou talvez a reejuste do tempo de execução da estrutura possa ajudar. Pode não ser uma solução segura, mas, olhando para a condição do problema, podemos querer experimentar várias soluções.

8.) Certifique -se de que você não está perdendo nenhum Atualização crítica do seu servidor Windows plataforma.

Eu tento lhe dar algumas idéias - o que faço se estivesse em sua posição.

Antes de tudo, dou uma longa olhada no monoterente.dll antes de alguns dias em que você faz sua pergunta e olho novamente hoje. Eu encontrei e a função que carrega a DLL. Minha primeira opinião é que algo tem a ver com as permissões.

Espero que você tenha acesso ao servidor - certo?

Meus primeiros passos é que:

Certifique -se de que o seu monoterente.dll atua tenha as permissões certas para o diretório do bin, para leitura e execute pelo seu aplicativo ASP.NET. Algumas vezes a cópia de uma DLL, não obteve as permissões de diretório, mas transportava suas próprias permissões. Para verificar se sua DLL tem permissões diferentes do resto, clique com o botão direito do mouse e consulte as propriedades | Segurança, vá para o diretório do bin e faça o mesmo e compare as permissões de segurança. Se eles forem diferentes, aplique novamente as permissões de diretório e verifique se a DLL herdada pelo diretório.

Meu segundo passo

Baixe o Processmonitor da SysInternals

http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx

Execute o Processmonitor e tente recriar o erro, pare e analise para ver onde e por que a DLL obtém as permissões negadas. Com o Processmonitor, você pode até ver se há alguma DLL que não possa ser encontrada!

Eu verifiquei as DLLs monotorrents e não achei nada incomum. Ele tem chamadas Kerner32.dll e usa código inseguro para ser executado, ok nada tão especial sobre.

Então, se você fizer 2 etapas e me dar algum feedback, talvez eu possa ir mais longe. (se não for resolvido por você e o que você encontra)

Eu aconselharia para configurar a manutenção regular provavelmente uma vez por semana no domingo à noite etc para a seguir,

  1. Exclua todos os arquivos temporários
  2. Exclua todos os arquivos temporários do ASP.NET IIS
  3. Reinicie o servidor

O problema é que os aplicativos da web asp.net fazem com que muitos arquivos de temperatura sejam deixados no disco, devido à compilação dinâmica de regex, assembléias de seriliazação etc., essas coisas temporárias nunca são excluídas, e cada vez mais lixo começa a ser coletado em locais de temperatura, O ASP.NET fica mais lento e mais lento, e um ponto entra em que o disco e a desfragmentação da memória atingem um ponto muito alto, as coisas começam a falhar.

Nenhum corpo gosta de reiniciar o servidor uma vez por semana, mas lembro que não tivemos escolha, no ASP.NET 1.1 tínhamos sistema estável após reiniciar todos os dias, no ASP.NET 2.0, estamos prontos para reiniciar programados de uma vez por semana .

Encontrei esse problema e faço tudo o que posso, como arquivo de temperatura claro, reiniciar o servidor, excluir e adicionar referência e também reconstruo a solução. No entanto, não consigo resolver esse problema. Finalmente, movo minha classe de entidade (quase deles precisa serializar) para a nova pasta que adicionei ao projeto e, em seguida, esse problema resolveu.

Este método é trabalho para mim.

O fuso horário do servidor é diferente do seu fuso horário? Eu tive esse problema ao implantar arquivos de recursos, o tempo de compilação estava no futuro para que eles não carregassem.

Modelos de formulários de usuário que contêm código podem ser publicados por administrações de coleta de sites para formar bibliotecas como soluções de sandbox.Para obter mais informações sobre soluções Sandboxed, Veja a visão geral das soluções sandboxed(SharePoint Server 2010) .Modelos de formulário que exigem confiança total ou usar uma conexão de dados que é gerenciada por um administrador deve ser implantada por um administrador.Para obter mais informações sobre modelos de formulário aprovados pelo administrador, consulte Gerenciar modelos de formulário aprovados pelo administrador (SharePoint Server 2010).

Eu sei que é simples, mas tive esse problema uma vez e foi porque eu tinha um projeto de aplicativo da web que contém

    References

Pasta e eu apenas copiei meus arquivos em um 

    Bin

pasta, em qualquer aplicativo da web .net no Propriedades do projeto Windows, uma Guia do caminho de referência está disponível que, por padrão, não deve ser incluído nele. Verifique esta opção e também Guia de construção dentro Janela de propriedades do projeto que Caminho de saída ser o mesmo que Bin

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top