Não é possível iniciar o debugging no servidor web. Não foi possível iniciar a debugging do ASP.NET VS 2010, II7, Win 7 x64

Estou executando o Visual Studio 2010 (como Admin), IIS 7 no Windows 7 x64. Eu sou capaz de executar o site do asp.net no IIS 7 sem debugging muito bem, mas quando eu pressionar F5 para depurá-lo, recebo:

Não é possível iniciar o debugging no servidor web. Não foi possível iniciar a debugging do ASP.NET. Mais informações podem estar disponíveis iniciando o projeto sem debugging.

Infelizmente, o link de ajuda não está me ajudando muito e leva até uma grande tree de coisas.

Eu verifiquei o seguinte:

  • Requisitos de segurança – não me lembro de ter que fazer nada de especial antes. O processo de trabalho no IIS7 é w3wp.exe. Ele diz que, se estiver sendo executado como ASPNET ou NETWORK SERVICE, devo ter privilégios de administrador para depurá-lo. Como descubro se preciso mudar alguma coisa aqui?

  • Páginas da propriedade do site> Opções de Início> Depuradores> ASP.NET está marcado. Use servidor personalizado é definido para o URL do site (que funciona bem sem debugging).

  • A debugging está habilitada no web.config .

  • O aplicativo está usando o ASP.NET 3.5 (eu quero mudar para o 4.0, eventualmente, mas eu tenho alguma migration para lidar com).

  • Pool de aplicativos: Classificando o AppPool .NET (também tentou o DefaultAppPool).

Alguma ideia de onde posso verificar a seguir?

Certamente não deve ser tão difícil instalar o IIS, VS, criar um site e começar a testá-lo?

Desde já, obrigado.

Tente ir ao IIS e verificar se o pool de aplicativos que você está usando está iniciado. Muitas vezes, você produzirá um erro que desliga o pool de aplicativos. Você só precisa clicar com o botão direito e iniciar e você deve estar pronto para ir.

Acontece que o culpado foi o módulo IIS Url Rewrite . Eu havia definido uma regra que redirecionava as chamadas para Default.aspx (que era definida como a página inicial do site ) para a raiz do site, para que eu pudesse ter uma URL doméstica canônica. No entanto, aparentemente VS teve um problema com isso e ficou confuso. Esse problema não aconteceu quando eu estava usando o Helicon ISAPI_Rewrite, então nem me ocorreu verificar.

Acabei criando um site totalmente novo do zero e transferindo projetos / arquivos pouco a pouco para minha solução e reconstruindo meu web.config até descobrir isso! Bem, pelo menos agora eu tenho um site um pouco mais limpo usando o .NET 4.0 (até agora, espero não correr em nenhuma parede) – mas que dor!

O Visual Studio, ao iniciar, tentará (por algum motivo) acessar o URL:

/debugattach.aspx

Se você tiver uma regra de reescrita que redireciona (ou captura de alguma outra forma), digamos, arquivos .aspx , em outro lugar, você receberá este erro. A solução é include esta seção no início da seção // do seu web.config :

      

Isso fará com que você capture este pedido específico, não faça nada e, mais importante, pare a execução para que nenhuma das suas outras regras seja executada. Esta é uma solução robusta, então sinta-se à vontade para manter isso em seu arquivo de configuração para produção.

Para o benefício de outros, no meu caso, eu tinha configurado o pool de aplicativos para usar minhas credenciais do Windows, a fim de acessar um compartilhamento de resources de rede. Desde a última vez que depurei a solução, redefini a senha do Windows. Senha alterada armazenada no pool de aplicativos e no bada bing.

Se a Identidade do ApplicationPool estiver configurada para a conta personalizada e a senha do computador for alterada, você deverá atualizar sua senha

Para o meu cenário, foi alterado para a seção httpErrors no web.config, configurando-o assim:

  

causou o problema “Não é possível iniciar a debugging no servidor da Web”. A configuração de volta para o valor anterior de “DetailedLocalOnly” corrigiu o problema. Indo um pouco mais a fundo, descobri que na verdade era apenas a configuração de erro 401 que estava causando isso:

    

Comentando a linha de erro 401 corrigiu o problema também, eu fui com isso desde que eu possa, então, manter o tratamento de erros personalizados e começar com a debugging.

Eu ainda não tenho ideia do porque isso está acontecendo.

Plasma verificar pool de aplicativos. se estiver parado. reinicie-o.

Tive o mesmo problema ao tentar depurar um módulo DNN (Dot Net Nuke). Acabou que você precisa ter compilation debug = “true”:

  

no seu web.config. Por padrão, é falso no DNN. Fonte original aqui: http://www.dnnsoftware.com/forums/forumid/111/postid/189880/scope/posts

Eu tenho exatamente o mesmo problema depois de implementar o módulo de reescrita.

Se eu remover as inputs de reconfiguração do meu arquivo web.config, a debugging funcionará perfeitamente.

Para contornar isso, eu apenas para comentar as tags reescritas durante a debugging, assim …

             

Eu então removo os comentários após a debugging.

Deve ser um bug no visual studio 2010.

Eu recebi o mesmo erro desde que o pool de aplicativos foi interrompido no IIS. Depois de iniciar o pool de aplicativos, o problema foi resolvido.

Aqui está o que eu fiz para limpar o erro que você anotou. Localize a pasta web do aplicativo dentro do sistema de arquivos, acesse Propriedades => Segurança clique no botão Avançado , clique na guia Proprietário , clique no botão Editar e altere o proprietário (com as permissions corretas) da pasta e marque a opção ” Repal. proprietário em sub-recipientes e objects “checkbox. Clique em ” Aplicar ” e, em seguida, eu estava no negócio (capaz de depurar).

Espero que isso funcione para outra pessoa.

Apenas finalmente consertou isso para minha única solução que estava tendo isso. Dois dos projetos da solução foram definidos como sites no IIS. Eu entrei e habilitei o ASP.Net Impersonation em Autenticação para ambos os projetos … e o VIOLA! FINALMENTE, não mais deste erro chato!

Eu estava recebendo a mesma mensagem de erro no VS 2012, mas não estava sendo executado como administrador. Quando eu executei o aplicativo como administrador, recebi uma mensagem diferente e um pouco mais útil (que consegui descobrir). HTH

Se o Pool de Aplicativos tiver problemas para reiniciar ou simplesmente não quiser reiniciar, verifique se o Windows fez atualizações recentes no ASP.NET v4.0 ou outro Pool de Aplicativos. Isso é o que aconteceu no meu caso. Eu simplesmente reiniciei meu computador, depois reiniciei o ASP.NET v4.0 App Pool e tudo estava funcionando de novo!

Dan …

Além das sugestões de Aaron, tente o seguinte

  • Verifique se a autenticação integrada do Windows está selecionada no site do IIS
  • Você pode depurar usando o Cassini em vez do IIS?

Tive o mesmo problema com o Windows 10 quando ligado todos os resources do Windows IIS. Mudou para o Windows 8.1 e teve problema novamente. A raiz estava no nome do site ” http: //MySite.local ” (não relacionado à versão do sistema operacional).

E a solução é simples

  • Editar arquivo de hosts em %SystemRoot%\System32\drivers\etc\

  • Adicionar linha com binding de ip: 127.0.0.1 MySite.local

Eu tive esse erro aparecer hoje devido a um defeito no código que estava enviando de volta uma quantidade enorme de vezes causando inundação de solicitações do IIS. Isso essencialmente bloqueou o IIS e, assim, quando tentei depurar, o tempo limite passou a tentar iniciar o depurador. Simplesmente reiniciei o IIS, o que levou alguns minutos e resolveu o problema.

Eu certamente gostaria que esse erro fosse menos genérico, parece que existem várias maneiras diferentes de produzi-lo.

Eu tive o mesmo problema no Visual Studio 2012 e 2013 no Windows 8.1. Para mim, a correção foi adicionar a Autenticação do Windows ao IIS usando ‘Ativar ou desativar resources do Windows’

Ativar ou desativar recursos do Windows

Certifique-se de que o pool de aplicativos do seu site use a versão de estrutura correta . Recebi o erro “Não foi possível iniciar a debugging” em um site do ASP.Net 2005. Foi incorretamente usando o DefaultAppPool no Windows 7 (que eu acredito que estava usando .Net Framework 4). Eu criei um novo App Pool baseado no .Net Framework 2 e o atribui ao site do problema. Depois disso, a debugging funcionou bem.

Verifique se o seu site no IIS não está parado.

Eu consertei colocar meu site para ser executado. : D

Eu tive esse problema e, eventualmente, percebi que eu ASP.net não está registrado corretamente com o IIS. Isso pode acontecer quando o servidor IIS é instalado antes do Visual Studio. Para corrigir este problema, use o comando aspnet_regiis -i Mais informações podem ser encontradas no link

teve mesmo problema. Se você tiver certificado SSL instalado no IIS e se você estiver tentando depurá-lo do Visual Studio, você precisará definir seu aplicativo no IIS para ignorar o certificado.

Eu tive o mesmo problema e achei que foi causado porque eu tinha um caractere typescript por engano no meu Web.config após a tag final. Meu Web.config ficou assim no final: h . O “h” era um caractere extra depois da tag de fechamento.

remova o sting assim: targetFramework = “4.0” no web.config ou altere o AppPool para a versão apropriada do framework.

Desinstalar o IIS UrlScan Extension resolveu o problema para mim.

Eu tinha enfrentado o mesmo problema, mas foi no próprio servidor de desenvolvimento web do Visual Studios, em vez de IIS. A volta é desmarcar a opção na guia Web em propriedades do projeto, Aplicar configurações do servidor a todos os usuários (armazenar no arquivo de projeto). Isso salvará o precioso tempo de alguns.

Eu tive o mesmo problema. Todas as respostas acima não funcionaram para mim. A solução foi excluir a pasta bin e obj manualmente.

Eu encontrei este problema também, mas foi mais parecido com o que o @Kirk explicou e a reescrita do URL.

No meu caso, alguém havia verificado essa alteração no arquivo web.config para um projeto MVC:

          

Como as extensões de arquivo .aspx não foram permitidas no servidor da Web, a URL /debugattach.aspx foi negada, impedindo a execução do depurador. Depois que eu removi essa configuração, funcionou novamente.

Eu tive o mesmo problema quando eu criei o aplicativo no Visual Studio e, em seguida, no diretório virtual criado de propriedades para uso com o IIS local. Se alguém tem esse erro é porque VS cria aplicativo sob AppPool errado, ou seja, sob AppPool que não atende às suas necessidades.
Se este for o caso, vá para o Gerenciador do IIS, selecione App, vá para configurações básicas e alterar AppPool para App e você está pronto para ir.

Eu recebi esse mesmo erro recentemente e, no meu caso, descobri que havia tipos MIME duplicados. Eu adicionei recentemente dois que não apareceram na lista inicialmente. O IIS me permite adicioná-los e foi somente quando decidi verificar os tipos MIME para o site novamente como parte do meu processo de diagnóstico que também recebi um erro no IIS. Referenciou duplicatas no web.config. Depois que voltei para o arquivo web.config, notei que uma nova seção chamada tinha sido adicionada, incluindo os dois tipos MIME recém-adicionados. Excluiu essa seção e a vida está boa novamente! Esperando que isso ajude outras pessoas que não conseguiram corrigir o problema com nenhuma das outras sugestões.