“O ponto de interrupção não será atingido no momento. O código fonte é diferente da versão original. ”O que isso significa?

Quando debugging no Visual Studio, às vezes eu adiciono um ponto de interrupção, mas é oco e VS diz: “O ponto de interrupção não será atingido no momento. O código-fonte é diferente da versão original.” Obviamente, isso me impede de ser capaz de depurar.

O que a mensagem significa? Qual versão original? Se acabei de abrir a solução e não fiz nenhuma alteração no código, como pode haver uma ‘versão original’?

Como se diz, o “código-fonte é diferente da versão original”.

Clique com o botão direito do mouse na pasta do projeto dentro do gerenciador de soluções e escolha Clean . Crie uma nova versão do projeto e o ponto de interrupção funcionará novamente!

Se você tiver desmarcado o projeto DLL na configuração de compilation de debugging , seu novo código nunca será criado!

Vá para Build --> Configuration Manager ... (no VS2010) e verifique se o projeto com o código que você está tentando depurar é verificado para a configuração de compilation atual.

Para mim, foi enquanto trabalhava em um projeto de site. Depois de limpar essas pastas temporárias, recebi os erros apropriados do compilador:

  • C:\Documents and Settings\%username%\AppData\Local\Temp\Temporary ASP.NET Files
  • C:\windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files

Eu finalmente resolvi o problema quando descobri que um arquivo de class que eu tinha movido intencionalmente para uma subpasta, de alguma forma reapareceu na pasta raiz. VS estava usando aquele enquanto eu estava editando o outro.

Você já fez isso?

Você gostaria de continuar e executar a última compilation bem-sucedida?

Se você marcou a checkbox e pressionou “Sim”, a última execução bem-sucedida será executada, mesmo que seu projeto não seja compilado. Isso significa que sempre que você definir um ponto de interrupção, receberá esse erro.

Tente alterar este valor:

  • Ferramentas
    • Opções
      • Projetos e Soluções
        • Construa e Corra
          • Em execução, quando ocorrem erros de criação ou implantação: não inicie

Vamos para

  • Ferramentas
    • Opções
      • Depuração
        • Geral

Desmarque Requer que os arquivos de origem correspondam exatamente à versão original

Selecione Depurar nas Configurações da Solução , em vez de Liberar

captura de tela do menu

Fechar o Visual Studio e reabrir a solução pode resolver o problema, ou seja, é um bug dentro do próprio IDE (estou executando o VS2010).

Se você tiver mais de uma instância do Visual Studio em execução, só precisará fechar a instância que está executando a solução com o problema.

Preste atenção na janela “Saída” no VS. Ele lhe dirá quais assemblies são carregados e quando. Você pode ver que uma versão mais antiga do seu assembly em algum lugar da pasta está sendo carregada.

Por exemplo, se você tiver vários conjuntos de módulos e atualmente estiver tentando dividir um dos assemblies de suporte, o CLR manipulará a solução de assembly, o que poderá carregar outro arquivo de assembly daquele que você referenciou no projeto.

Uma nova maneira de obter esse problema apareceu no Visual Studio 2017 15.3.1 a 15.3.5. Se você estiver usando o EditorConfig , a opção charset=utf8 causa esses sintomas. A equipe do VS reproduziu isso e disse que eles estão trabalhando nisso .

Então, uma correção é comentar a sua linha charset=utf8 no arquivo .editorconfig.

Edit: Isso deve ser corrigido a partir do VS 15.5.

Isso também acontece com frequência se você estiver usando referências de arquivo a binários (em vez de referências de projeto a código em seu projeto), e o binário compilado que você está referenciando cai fora de sincronia com o código-fonte correspondente em sua máquina. Isso pode acontecer porque você fez o download de uma nova versão do binário do controle de origem sem o novo código-fonte, ou você tem algumas versões do binário em sua máquina e está fazendo referência a uma cópia antiga, etc. o problema, é uma boa razão para usar referências de projeto tanto quanto possível.

Há um cenário quase imperceptível que resolveu esse problema para mim. Se houver um arquivo de origem específico no qual o ponto de interrupção não está ocorrendo, ele poderá ser listado em

  • Gerenciador de Soluções
    • clique com o botão direito em Solução
      • Propriedades
        • Propriedades Comuns
          • Depurar arquivos de origem
            • “Não procure por esses arquivos de origem”.

Por alguma razão desconhecida para mim, o VS 2013 decidiu colocar um arquivo fonte lá, e subsequentemente, eu não consegui mais atingir o ponto de interrupção no arquivo. Isso pode ser o culpado pelo “código-fonte é diferente da versão original”.

Isso pode acontecer quando a hora do sistema muda durante a debugging ou entre as sessões de debugging, seja programaticamente, manualmente ou por um programa externo.

Para mim, nenhum dos itens resolveu o problema. Acabei de adicionar uma nova linha de código dentro dessa function, algo como:

 int a=0; 

adicionando isso, eu acho que acionei o visual studio para adicionar essa function à versão original

Você pode obter essa mensagem quando estiver usando um ativador e a assembly na qual você definiu o ponto de interrupção ainda não foi carregada.

O ponto de interrupção resolverá quando o ativador carregar a assembly (supondo que os símbolos de assembly e debugging estejam atualizados). Um bom lugar para olhar é a janela de módulos no menu de debugging. Lá você deve procurar a assembly à qual seu arquivo pertence também. Primeiro, verifique se o conjunto está carregado. Então, de onde está carregado? Então, o arquivo de símbolos é carregado. Novamente, de onde o arquivo de símbolos é carregado? Por fim, verifique as versões de ambos.

Eu também encontrei isso. As condições que causaram o meu problema:

  • Estou executando uma instância completa do IIS7 localmente
  • Estou versionando meu software em projetos separados

Eu tinha causado isso abrindo uma versão anterior (VS solicitado a perguntar se eu queria apontar para esta instância na debugging do IIS, eu respondi ‘Sim’), em seguida, abrir a versão atual (mais uma vez respondendo ao prompt do IIS com um ‘Sim’) ), em seguida, tentar depurar na versão anterior.

Para resolver, eu simplesmente fechei e reabrei a versão anterior e pretendida, mais uma vez afirmando como a fonte de debugging.

Isso acontece também ao depurar um projeto C ++ que carrega um módulo que foi implementado com alguma linguagem CRL (Managed C ++, C # etc). Nessa situação, a mensagem de erro é realmente enganosa.

A solução é colocar a propriedade de configuração de suporte Common Language Runtime (CLR) no projeto de boot e recompilar isso.

O problema é que suas informações de debugging não estão sincronizadas com seu assembly. A solução é simples:

  1. Vá para a sua pasta bin
  2. Remova os arquivos .pdb
  3. Reconstruir

Deve fazer o truque!

(O estranho é que, uma reconstrução sem jogar fora os arquivos .pdb nem sempre funciona. Eu posso ver a data de modificação sendo atualizada, mas ainda em algum lugar na cadeia (depurador VS2013, IIS, cache de assembly) essa alteração não é detectada )

Para mim, a solução estava oculta nas Advanced Build Settings das propriedades do projeto: insira a descrição da imagem aqui

Por um motivo desconhecido, ele foi definido como none : configurá-lo para full causou a quebra dos pontos de interrupção.

Para chegar a essa checkbox de diálogo, abra as propriedades do projeto, vá para Build e selecione o botão Advanced... na parte inferior da página.

vamos para:

Ferramentas> Opções> Depuração> Geral> desmarcadaRequer que os arquivos de origem correspondam exatamente à versão original

No meu caso, eu estava anexando a um processo em execução no VS 2012. Ao append, você tem a opção de depurar em vários modos (nativo, script, silverlight, gerenciado 2.0, gerenciado 4.0, etc). Por padrão, o depurador seleciona o modo automaticamente. No entanto, Automático nem sempre faz a escolha correta. Se o seu processo contiver vários tipos de código, verifique se o depurador está usando o correto.

No meu caso, eu estava desenvolvendo um aplicativo do Windows CE, que testava contra um emulador. O problema é que o executável não foi implantado no emulador, portanto, o .pdb (no ambiente de desenvolvimento) estava fora de sincronia com o .exe (no emulador), porque o novo .exe nunca foi copiado para o emulador. Eu tive que excluir o exe no emulador para forçar uma nova implantação. Então funcionou.

Tente desabilitar e redefinir o ponto de interrupção durante a execução no modo de debugging em vez de executá-lo antes de iniciar o modo de debugging.

O que funcionou para mim foi mudar a plataforma da solução de x86 para Any CPU. Depois de mudar para Any, eu defini um endereço de parada, corri o site, abri a página, cliquei no botão e ele parou. Fechei o site, mudei de volta para x86 e executei a mesma sequência com sucesso.

No Windows 7, Visual Studio Express 2010, se você tiver ativado a opção Usar modo de compatibilidade para o Windows XP SP3 , esse erro poderá ocorrer.

Eu desmarcada a opção e funcionou perfeito novamente. Clique com o botão direito do mouse no atalho para VS ou no executável, selecione propriedades e, em seguida, compatibilidade .

Primeiro eu tentei na linha de comando;

A exclusão de arquivos temporários da linha de comando funcionou.

C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ Arquivos ASP.NET temporários> raiz rd / s

Quando desativo a opção “Ativar apenas meu código” em Ferramentas -> Opções -> Depuração -> Geral

O problema resolveu para mim. É um aplicativo WCF, estava tentando depurar uma página ashx. http://blogs.msdn.com/b/zainnab/archive/2010/10/25/understanding-just-my-code.aspx

Se você tiver mais de um projeto em sua solução , verifique se o projeto correto está definido como o StartUp Project . Para definir um projeto específico como o projeto de boot da sua solução, clique com o botão direito do mouse no projeto, escolha Set As StartUp Project .

Depois de definir corretamente o meu projeto de boot, o ponto de interrupção desejado foi atingido pelo encadeamento.

Eu experimentei isso em uma compilation de 32 bits em vs2017.

Exatamente nenhuma das soluções funcionou para mim. Eu reiniciei, limpei os arquivos IDE, limpei a solução criada, peguei o git repo e reconstruí a solução sem sucesso.

Eu estava puxando uma dependência de 64 bits da nuget e assim que eu usei a assembly, as fonts não estavam mais sendo construídas no executável final e, em vez disso, as fonts em cache do IDE estavam sendo construídas.

Eu removi a configuração do nuget, removi o assembly referenciado, fiz o download da fonte, criei o log4net manualmente, assinei-o, adicionei-o a uma pasta em meu projeto, adicionei referência a ele e consegui depurar novamente.

Isso foi uma dor, espero que fique na lista de respostas para todos verem.

Edit: Não houve erro durante a compilation apesar de ter a opção “prompt de erro de compilation” sendo ativada nas configurações do IDE.

Se o seu processo depurado contiver vários appdomains eo assembly for carregado em ambos, e um deles estiver carregando uma cópia antiga (geralmente algo carregado dinamicamente como um plug-in), o ponto de interrupção pode parecer sólido, mas o encadeamento que deve atingir o ponto de interrupção está no appdomain com o assembly antigo e nunca acessa. Você pode ver quais assemblies são carregados e seu caminho na janela do módulo.

Verifique se você tem mais de um arquivo com esse nome na solução.

Eu tive isso em um projeto que eu assumi de outra pessoa. A lista de pontos de interrupção estava cheia de números de linha no Controller.cs, alguns ativos e outros não. Eu encontrei essa pergunta e tentei algumas opções, mas quando clico duas vezes nos pontos de interrupção, eles me levaram para diferentes projetos dentro da solução. Como os arquivos eram chamados de iguais, eles parecem ser os mesmos, mas não são. A resposta é, obviamente, ignorar o aviso, pois eles se tornarão ativos se você carregar esse outro arquivo.

Aconteceu que estava no Visual Studio 2017 depois que eu adicionei os arquivos existentes ao projeto. Isso funcionou para mim:

  1. feche a solução,
  2. vá para SolutionFolder\.vs\SolutionName\v15\sqlite3 e remova storage.ide
  3. abra a solução novamente