Acabei de atualizar do Visual Studio 2013 para 2015 e agora estou tendo problemas com pontos de interrupção.
É um acerto ou um erro onde os pontos de interrupção realmente funcionam e se eu definir um durante a depuração, recebo o erro:
O ponto de interrupção falhou ao ligar.
Qualquer ajuda seria apreciada. Estou prestes a desistir de 2015 e voltar.
Respostas:
Eu tive o mesmo problema, mas uma solução diferente. Observe que atualizei para o VS 2015 Update 1 e o problema ainda está lá.
Na edição anterior do VS, o início da depuração acionava automaticamente uma compilação no modo de depuração. Mas com o VS2015 isso não acontece.
Portanto, se sua última compilação estava no modo de lançamento e você tenta depurar, o ponto de interrupção não funcionará.
Você precisa criar manualmente no modo de depuração primeiro e depois iniciar a depuração.
Eu tive o mesmo problema.
Resolvi desabilitar a opção "Otimizar código" na guia Build das propriedades do projeto.
Isso pode parecer trivial, mas depois de muitos headscratchs com os mesmos problemas que você mencionou, descobri que minha compilação estava configurada para "release" em vez de "debug" quando tentei depurar .. reconstruindo a solução para "debug "corrigi-lo e eu poderia definir pontos de interrupção normalmente
Eu tive um problema semelhante com os pontos de interrupção que não ligavam, bem como certas variáveis locais que não foram avaliadas na janela Locals. O que finalmente foi corrigido foi ativar a opção "Suprimir otimização JIT na carga do módulo (somente gerenciado)" na guia Opções-> Depurar-> Geral. Uma vez eu configurei que era capaz de vincular sem problema.
Eu tive esse problema. Executei uma sessão de perfil de desempenho que modificou o Web.configarquivo com as configurações do monitor de desempenho:
<appSettings>
<add key="Microsoft.VisualStudio.Enterprise.AspNetHelper.VsInstrLocation" value="C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Team Tools\Performance Tools\vsinstr.exe"/>
</appSettings>
<compilation debug="true" targetFramework="4.5"
assemblyPostProcessorType="Microsoft.VisualStudio.Enterprise.Common.AspPerformanceInstrumenter, Microsoft.VisualStudio.Enterprise.AspNetHelper, Version=16.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
...
</compilation>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Microsoft.VisualStudio.Enterprise.AspNetHelper" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<codeBase version="16.0.0.0" href="file:///D:/Program%20Files%20(x86)/Microsoft%20Visual%20Studio/Shared/Common/VSPerfCollectionTools/vs2019/Microsoft.VisualStudio.Enterprise.AspNetHelper.DLL"/>
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="VsWebSite.Interop" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<codeBase version="8.0.0.0" href="file:///D:/Program%20Files%20(x86)/Microsoft%20Visual%20Studio/Shared/Common/VSPerfCollectionTools/vs2019/VsWebSite.Interop.DLL"/>
</dependentAssembly>
</assemblyBinding>
</runtime>Isso quebrou minha capacidade de parar nos pontos de interrupção. Quando voltei ao Web.config original (removi as configurações do Performance Profiler), os pontos de interrupção começaram a funcionar novamente.
<add key="Microsoft.VisualStudio.Enterprise.AspNetHelper.VsInstrLocation" value="C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Team Tools\Performance Tools\vsinstr.exe"/>
Eu tive o mesmo problema ontem. Eu usei o recurso "Solução Limpa" e ajudou.
a solução é desativar a otimização do design.
Project Properties> Build> Advanced Compile Options> Enable Optimizations
Executo o desempenho na minha solução e isso foi adicionado ao meu web.config
<compilation debug="true" targetFramework="4.5" assemblyPostProcessorType="Microsoft.VisualStudio.Enterprise.Common.AspPerformanceInstrumenter, Microsoft.VisualStudio.Enterprise.AspNetHelper, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/> o assemblyPostProcessorTypeé o problema, eu apaguei e isso resolveu o meu problema
Mude o modo Release para Debug. No meu caso, isso corrigiu meu problema.
Não alterei a configuração 'otimizar', mas com base em outras respostas aqui,
Até agora, isso foi corrigido para mim. Parece que a atualização para o VS2015 Update 2 trouxe algumas coisas no meu sistema.
Sei que este é um post antigo, mas, caso todos os outros truques acima não funcionem, verifique se a imagem que está tentando depurar está atualizada. Por algum motivo, depois de publicar e transferir um projeto .NET Core para o meu Raspberry Pi 'descompactar' no RPi, não estava copiando nem substituindo algumas DLLs no diretório ativo. Quando anexei o depurador, achando que estava tudo bem, alguns pontos de interrupção estavam sendo atingidos, outros não e outros estavam me dando o erro "não é possível vincular". Depois que resolvi o problema de descompactar, todos os meus pontos de interrupção e símbolos voltaram. Eu espero que isso ajude.
Encontrei os erros de ponto de interrupção de ligação hoje. E eu resolvi meu problema fazendo belows.
Se todas as suas configurações de depuração não estiverem corretas, não será possível corrigir o problema fazendo o seguinte.
Talvez essa solução ajude alguém.
Eu tive o mesmo problema, mas não percebi que "Debug" havia mudado para "Release" na barra de ferramentas de depuração (geralmente diretamente no menu). Então, eu defini-lo para "Debug" funcionou.
A nova atualização para o Microsoft Visual Studio 2015, atualização 3 (KB3165756) corrigiu o problema de ponto de interrupção para mim, onde estou tentando inspecionar as variáveis locais no código C # incorporado nos arquivos cshtml nos aplicativos ASP.NET Core.
PASSO 1, descarte o óbvio:
PASSO 2 Para projetos C ++:
Verifique as seguintes propriedades do projeto:
Faça o passo 1 novamente
Você pode tentar adicionar __debugbreak (). Esta declaração precisa ir no seu arquivo de origem onde você deseja quebrar.
PASSO 2 Para projetos em C #:
Tente abrir sua solução em outras máquinas. Se você pode vincular um ponto de interrupção em uma máquina diferente, isso pode significar um problema no seu VS ou no seu SO.
PASSO 3, verifique se o seu VS está atualizado:
Houve relatos de problemas como esse no VS2013 RTM, bem como no VS2015 Update 1 e Update2.
No VS, vá para Ferramentas / Extensões e atualizações / Atualizações / Atualizações do produto e veja qual versão você está executando. Se for necessária uma atualização, ela aparecerá lá.
PASSO 4, verifique se o seu sistema operacional está atualizado:
Por fim, se você estiver executando um sistema operacional Win 10, houve um bug relatado sobre esse problema que existia no build 14251. Isso foi resolvido no build 14257 (e acima).
Acabei de encontrar um problema semelhante e nenhuma das respostas aqui foi encontrada sobre o problema que estava enfrentando. Ao contrário da pergunta, porém, nunca recebo nenhuma mensagem dizendo que houve uma falha no vínculo. O ponto de interrupção nunca chega. Espero que isso seja útil para alguém no futuro batendo a cabeça na parede com o WCF.
TL / DR:
Na mensagem SOAP, houve um registro com dados incorretos, causando o ponto de interrupção não ser atingido.
História completa:
Eu tenho um serviço WCF baseado no WSDL de outra equipe. Não é minha definição, não tenho controle sobre isso ... Recebo mensagens dessa outra equipe por meio deste serviço. No meu caso, recebo mensagens, posso registrar a mensagem na tabela de log de mensagens no banco de dados (o que acontece antes da chamada do meu método de serviço), o método do serviço é aparentemente chamado (talvez não seja) e o servidor responde com a 202 Aceito. A comunicação está funcionando, exceto que nenhum dado é salvo no banco de dados durante a chamada do método.
Como o serviço retorna uma resposta bem-sucedida, excluí questões relacionadas a http e transporte.
Então, iniciei o VS2015 para depurar o serviço. A mensagem em questão é grande, mas está dentro dos limites do que eu esperaria. Coloquei um ponto de interrupção na primeira linha do método de serviço e enviei a mensagem grande, mas o ponto de interrupção nunca foi atingido. Tentei uma mensagem menor que sabia funcionar na mesma instância de execução e o ponto de interrupção foi atingido perfeitamente. Então, tudo na configuração parecia bem. Eu pensei que talvez houvesse algo no tamanho da mensagem.
Eu tentei tudo o que pude encontrar - certificando-me de que estava em uma configuração de depuração, limpo e reconstruído, anexando manualmente o depurador ao processo w3wp (que o VS já estava), usando em Debugger.Break()vez de um ponto de interrupção, definindo vários projetos de inicialização, descarregando meu projeto de teste para que o projeto de serviço fosse o único, atualizando o .NET, reiniciando o VS2015, reiniciando, alternando do IIS local para o IIS Express e vice-versa, recriando o serviço com o WSDL mais recente garantido. Nada importava. O ponto de interrupção nunca foi atingido.
Acabei tendo que eliminar registros da mensagem grande, um por um, até encontrar um único registro com dados incorretos. No meu caso, era um registro que não tinha valor para 2 campos DateTime. Quando criei uma mensagem que continha apenas este registro e a enviei, o ponto de interrupção não foi atingido. Quando forneci valores para esses 2 campos DateTime e enviei a mesma mensagem (fixa) no ponto de interrupção, disparada conforme o esperado.
Eu tinha todas as exceções CLR ativadas, nada foi acionado além de arquivos .pbd ausentes, dos quais não me importava. O WCF felizmente enviou a solicitação com um registro ruim. Não estou dizendo que o WCF não deveria ter enviado com base nos contratos, apenas que o registro ruim fez com que o ponto de interrupção não fosse atingido.
Eu tive que modificar o arquivo web.config para habilitar a depuração. Mude isso:
<compilation debug="true" targetFramework="4.5.2" assemblyPostProcessorType="Microsoft.VisualStudio.Enterprise.Common.AspPerformanceInstrumenter, Microsoft.VisualStudio.Enterprise.AspNetHelper, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>para:
<compilation debug="true"/>Eu tentei tudo sugerido aqui. Eventualmente, defino a "Página específica" em Propriedades do projeto -> Web como minha URL de início local, página e parâmetro de consulta. Fiz uma limpeza e reconstrução no modo de depuração e atingiu meu ponto de interrupção.
Embora essa seja uma versão muito posterior (VS2017), tive esse problema com projetos C #. Tentei limpar, reconstruir, reiniciar o visual studio, etc.
O que foi corrigido foi fechar o Visual Studio e excluir a pasta .vs, que é uma pasta oculta localizada no diretório da solução. A exclusão da pasta .vs não deve causar problemas, embora você precise redefinir seu projeto de inicialização.
Eu olhei as respostas anteriores e @ de Will answear fixa o principal problema que eu estava tendo, o outro sendo capaz de editar e continuar, mas tendo um olhar mais atento sobre o arquivo AssemblyInfo.cs eu descobri alguma depuração apresenta onde desativado.
Então eu acabei removendo os atributos de depuração antigos e adicionando o seguinte que tirei de outro projeto
#if DEBUG
[assembly: System.Diagnostics.Debuggable(System.Diagnostics.DebuggableAttribute.DebuggingModes.DisableOptimizations | System.Diagnostics.DebuggableAttribute.DebuggingModes.EnableEditAndContinue | System.Diagnostics.DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints | System.Diagnostics.DebuggableAttribute.DebuggingModes.Default)]
#endifNo entanto, sinto que essa não é a melhor maneira de fazê-lo.