o arquivo de origem é diferente de quando o módulo foi construído

Isto está me enlouquecendo.

Tenho um projeto bastante grande que estou tentando modificar. Notei anteriormente que, quando digitei DbCommand, o visual studio não fez nenhum realce de sintaxe nele, e estou usando System.Data.Common.

Mesmo sem nada destacado, o projeto parecia estar funcionando bem no meu navegador. Portanto, decidi executar o depurador para ver se as coisas estavam realmente funcionando como deveriam.

Cada vez que a turma que não fez o destaque é chamada, recebo a "the source file is different from when the module was built"mensagem.

Limpei a solução e a reconstruí várias vezes, excluí arquivos tmp, segui todas as instruções aqui Obtendo "O arquivo de origem é diferente de quando o módulo foi construído." , reiniciou o servidor da web e ainda me diz que os arquivos de origem são diferentes quando claramente não são.

Não posso testar nenhum código que escrevi hoje por causa disso.

• Como a fonte pode ser diferente do binário quando acabei de cumpri-lo?
• Existe alguma maneira de colocar algum sentido no estúdio visual ou estou apenas perdendo alguma coisa?

Eu tive esse problema ao executar um aplicativo de console em que a fonte que era diferente era a fonte que tinha o ponto de entrada (estático void Main). Excluir os diretórios bin e obj e fazer uma reconstrução completa parecia corrigir isso, mas toda vez que eu fazia uma alteração no código, ele ficava desatualizado novamente.

O motivo que encontrei para isso foi:

1. Eu tinha marcado "Apenas construir projetos de inicialização e dependências em Executar" (Ferramentas -> Opções -> Projetos e Soluções -> Construir e Executar)
2. No Configuration Manager, meu projeto de inicialização não tinha "Build" marcado

(Para # 2 -> acessível através da barra de ferramentas na lista suspensa 'Depurar / Liberar'.)

Eu estava tendo o mesmo problema, meus projetos estavam todos na mesma solução, então eles estavam usando referências de projeto a projeto, então quando um mudou, os outros deveriam ter sido atualizados. Porém, não foi o caso, tentei construir, reconstruir, fechar o VS2010, puxar uma nova cópia do nosso controle de origem. Nada disso funcionou, o que finalmente acabei tentando foi clicar com o botão direito no projeto e reconstruir cada projeto individualmente. Isso atualizou os arquivos .dlls e .pdb para que eu pudesse depurar.

O problema aqui é que seus arquivos dll e / ou pdb não estão sincronizados.

Siga esses passos

1. Basta excluir o diretório bin do projeto onde a DLL é gerada.
2. Reconstrua o projeto.
3. Remova do projeto a referência que faz referência à DLL.
4. Inclua novamente a referência.
5. Aproveitar.

Além dessas respostas, tive o mesmo problema ao substituir novas DLLs por antigas devido ao caminho errado. Se ainda estiver recebendo esse erro, você não pode referir o caminho errado para as DLLs. Vá para o gerenciador de IIS e clique no site que usa suas DLLs. Na janela à direita, clique em Configurações Avançadas e vá para o caminho da pasta Caminho Físico no Explorador de Arquivos e certifique-se de estar usando esta pasta para substituir suas DLLs.

Algumas coisas para você verificar:

Você verificou as referências do seu projeto?

Você tem um servidor web iniciado do Visual Studio ainda em execução? Verifique a bandeja do sistema e procure uma página com um ícone de engrenagem (você pode ter mais de uma):

_{(fonte: msdn.com )}

Clique com o botão direito e feche / saia. Você pode ter mais de um. Você pode depurar suas alterações agora?

Você está executando a versão de depuração, mas criou apenas a versão de lançamento (ou vice-versa)?

A compilação realmente teve sucesso? Sei que cliquei no link "ocorreram erros, deseja continuar mesmo assim?" mensagem algumas vezes sem perceber.

Com os serviços da Web, o problema pode ser causado pelo uso do comando "Exibir no navegador" do Visual Studio. Isso coloca os arquivos DLL e PDB do serviço nas pastas bin e obj. Ao entrar no serviço da web de um cliente, de alguma forma, o Visual Studio usa o PDB na pasta bin (ou obj), mas usa a DLL na pasta de compilação de saída do projeto. Existem algumas soluções alternativas:

1. Tente excluir os arquivos DLL e PDB nos arquivos bin e obj do serviço da web.
2. Tente clicar em "Exibir no navegador" no Visual Studio.

Se você obteve anteriormente o erro de incompatibilidade do arquivo de origem, o Visual Studio pode ter adicionado o nome do arquivo a uma lista negra. Verifique as propriedades da solução. Escolha "Propriedades comuns -> Arquivos de origem de depuração" no lado esquerdo da caixa de diálogo. Se seus arquivos de origem de serviço da web aparecerem no campo "Não procure por esses arquivos de origem", exclua-os.

Eu só tive esse problema.

Tentei todos os itens acima, mas apenas funcionou:

• exclua o arquivo .pdb da solução.
• exclua os arquivos .obj ofensivos (para o arquivo relatado fora de sincronia)

construir a solução.

Isso corrigiu o problema de todas as versões futuras para mim.

Foi assim que resolvi o problema no Visual Studio 2010:

1) Altere a opção 'Configurações de soluções' de "Depurar" para "Liberar"

2) Comece a depurar

3) Pare a depuração e mude a opção 'Configurações de soluções' de volta para "Depurar"

Isso funcionou para mim. A etapa 3 é opcional - estava funcionando bem quando mudei para "Release", mas eu queria alterá-la novamente.

Minha solução:

Eu havia incluído um projeto existente de uma solução diferente em um novo arquivo de solução.

Não percebi que, quando o projeto existente foi reconstruído, ele estava colocando a saída final no diretório de saída da solução NOVA. Eu tinha um caminho de vinculador definido para examinar o diretório de saída da solução ANTIGA.

Mudar meu projeto para pesquisar no diretório de saída da nova solução corrigiu esse problema para mim.

Tive esse problema e descobri que estava executando meu aplicativo de console como um aplicativo do Windows. Alternar o tipo de saída de volta para o console corrigiu o problema.

Eu tive o mesmo problema. Para consertar, usei o "Modo de Liberação" para depurar no VS2013. O que é suficiente para mim, porque estou trabalhando em um addon js \ c ++ node.

Descarregue o projeto que contém o arquivo que está causando o erro.

Recarregue o projeto.

Fixo

No Visual Studio 2017, excluir a pasta .vs oculta no resolveu esse problema para mim.

Meu problema era que eu tinha dois projetos em minha solução. O segundo foi um projeto de teste usado para chamar o primeiro. Eu tinha escolhido o caminho para as referências da pasta de lançamento da pasta bin.

Portanto, sempre que eu fizesse uma alteração no código do primeiro projeto e o reconstruísse, ele atualizaria as dlls na pasta de depuração, mas o projeto de chamada estava apontando para a pasta de lançamento, dando-me o erro ", o arquivo de origem é diferente de quando o módulo foi construído."

Depois de excluir a referência à dll do projeto principal na pasta de lançamento e configurá-la como dll na pasta de depuração, o problema foi embora.

solução: - o problema é: - se seus alguns projetos estão em uma solução, referem-se a alguns outros projetos, então às vezes a dll de alguns projetos não será atualizada automaticamente, sempre que você construir a solução, alguns projetos terão dlls de construção anteriores, não últimas dlls

você tem que ir manualmente e copiar a dll do último projeto de construção para o projeto referenciado

Eu estava usando o Visual Studio 2013 e tinha um projeto existente sob controle de origem.
Eu tinha baixado uma nova cópia do controle de origem para um novo diretório.
Depois de fazer alterações na nova cópia, ao construir recebi o erro em questão.

Minha solução:
1) Abra Documents\IISExpress\config\applicationhost.config
2) Atualize o virtualDirectorynó com o diretório para a nova cópia e salve.

Meu problema era que eu tinha um serviço da web no projeto e mudei o caminho de construção.

Restaurar o caminho de construção padrão resolveu meu problema.

Eu tive esse mesmo problema e segui a maioria das orientações nas outras respostas postadas aqui, nada parecia funcionar para mim.

Por fim, abri o IIS e reciclei o pool de aplicativos do meu aplicativo da web. Tenho o IIS versão 8.5.9600, cliquei com o botão direito do mouse em meu aplicativo da web e: Implantar> Reciclar> Reciclar pool de aplicativos> OK.

Isso parece ter corrigido o problema, os pontos de interrupção agora sendo atingidos conforme o esperado. Acho que fazer isso junto com a exclusão das pastas bin e obj ajudou a minha situação.

Boa sorte!

Eu sei que essa é uma pergunta antiga mas eu só tive o mesmo problema e queria postar aqui caso ajude alguém. Eu comprei um novo computador e o departamento de TI fundiu meu computador antigo com o novo. Quando configurei o TFS, mapeei um caminho local diferente do que estava usando anteriormente, para uma unidade interna adicional. O caminho antigo ainda existia a partir dos dados mesclados em meu disco rígido, então eu ainda poderia construir e executar. Meus caminhos do IIS também apontavam para o diretório antigo. Depois de atualizar o IIS para o caminho correto, consegui depurar perfeitamente. Eu também apaguei o diretório antigo para uma boa medida.

Eu também experimentei isso. Acabei de abrir a pasta obj no projeto e, em seguida, abrir a pasta de depuração, excluir o arquivo .pdb e isso é tudo.

Este erro também ocorre se você tentar fazer alterações em um arquivo de origem que não faz parte do projeto.

Eu estava depurando um método de um .dll de outro de meus projetos, onde o Visual Studio carregou o código-fonte de forma bastante útil, porque o .dll foi criado na mesma máquina e sabia o caminho para o código-fonte. Obviamente, alterar esse arquivo não fará nada a menos que você reconstrua o projeto referenciado.

1. Exclua todos os pontos de interrupção.
2. Reconstruir.
3. Feito

No Visual Studio 2015, usando C ++, o que corrigiu para mim o the source file is different from when the module was builtproblema foi

• reinicie o Visual Studio.

Depurar-> iniciar sem depuração.

Essa opção funcionou para mim. Espero que isto ajude!

Verifique se a localização que você apontou usando mex () no Matlab está correta (contém os arquivos lib e obj que foram modificados para a última data em que você compilou a biblioteca no Visual Studio).

Se este não for o caso:

Certifique-se de compilar o Visual Studio em um modo que salve arquivos .lib:

1. propriedades -> Propriedades de configuração -> Geral -> Tipo de configuração -> biblioteca estática

2. propriedades -> Propriedades de configuração -> Geral -> Extensão de destino = .lib (em vez de exe)

Certifique-se de que os diretórios de saída e intermediários correspondam ao diretório Matlab em

1. propriedades -> Propriedades de configuração -> Geral -> Diretório de saída
2. propriedades -> Propriedades de configuração -> Geral -> Diretório intermediário

No meu caso, a resposta do @Eliott não funciona. Para resolver este problema que tive Excluir / Incluir De Projeto meu arquivo deficiente, andalso limpa e reconstruir a solução.

Após essas ações, meu arquivo com minhas últimas modificações e o depurador são restaurados.

Espero esta ajuda.

Eu recebo esse problema ao depurar às vezes com Visual Studio, mas quando o aplicativo é servido por IIS . (temos que desenvolver neste formulário por alguns motivos complicados que têm a ver com a forma como o desenvolvedor original configurou este projeto.)

Quando eu mudo o arquivo e o reconstruo , isso corrige muitas vezes. Eu sei que parece bobo, mas eu estava apenas tentando depurar algum código para ver por que ele está fazendo algo estranho quando não o altero há um tempo, e tentei uma dúzia de coisas nesta página, mas foi corrigido apenas com a mudança o arquivo..