O Visual Studio 2010 sempre acha que o projeto está desatualizado, mas nada mudou

Eu tenho um problema muito semelhante ao descrito aqui .

Também atualizei uma solução mista de projetos C ++ / CLI e C # do Visual Studio 2008 para o Visual Studio 2010. E agora, no Visual Studio 2010, um projeto C ++ / CLI sempre fica desatualizado.

Mesmo que tenha sido compilado e ligado um pouco antes e F5 seja atingido, a checkbox de mensagem “O projeto está desatualizado. Deseja compilá-lo?” aparece. Isso é muito chato porque o arquivo DLL é de nível muito baixo e força quase todos os projetos da solução a serem recriados.

Minhas configurações de pdb estão definidas para o valor padrão ( solução sugerida deste problema ).

É possível obter o motivo pelo qual o Visual Studio 2010 força uma reconstrução ou acha que um projeto está atualizado?

Alguma outra idéia por que o Visual Studio 2010 se comporta dessa maneira?

Apenas para o Visual Studio / Express 2010. Veja outras respostas (mais fáceis) para VS2012, VS2013, etc

Para localizar o (s) arquivo (s) ausente (s) , use as informações do artigo Ativar o log do sistema de projeto C ++ para habilitar o log de debugging no Visual Studio e deixar apenas informar o que está causando a reconstrução:

  1. Abra o arquivo devenv.exe.config (encontrado em %ProgramFiles%\Microsoft Visual Studio 10.0\Common7\IDE\ ou em %ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\ ). Para versões do Express, o arquivo de configuração é denominado V*Express.exe.config .
  2. Adicione o seguinte após a linha :

          
  3. Reinicie o Visual Studio
  4. Abra o DbgView e verifique se ele está capturando a saída de debugging
  5. Tente depurar (pressione F5 no Visual Studio)
  6. Procure no log de debugging por qualquer linha do formulário:

    devenv.exe Informação: 0: Projeto ‘Bla \ Bla \ Dummy.vcxproj’ não está em dia porque a input de compilation ‘Bla \ Bla \ SomeFile.h’ está faltando.

    (Acabei de pressionar Ctrl + F e procurei por not up to date ) Estas serão as referências que farão com que o projeto fique perpetuamente “desatualizado”.

Para corrigir isso, remova qualquer referência aos arquivos ausentes de seu projeto ou atualize as referências para indicar seus locais reais.

Nota: se usar 2012 ou mais tarde, o snippet deve ser:

      

No Visual Studio 2012, consegui obter o mesmo resultado mais fácil do que na solução aceita.

Alterei a opção no menu FerramentasOpçõesProjetos e soluçõesCriar e executar → * Detalhamento de saída de compilation do projeto MSBuild “de Mínimo para diagnóstico .

Em seguida, na saída da compilation, encontrei as mesmas linhas pesquisando “não atualizado”:

Projeto ‘blabla’ não está atualizado. O item de projeto ‘c: \ foo \ bar.xml’ tem o atributo ‘Copiar para o Diretório de Saída’ definido como ‘Copiar sempre’.

Isso aconteceu comigo hoje. Consegui localizar a causa: o projeto incluía um arquivo de header que não existia mais no disco.

Remover o arquivo do projeto resolveu o problema.

Também nos deparamos com esse problema e descobrimos como resolvê-lo.

O problema foi como afirmado acima “O arquivo não existe mais no disco.”

isto não está correto. O arquivo existe no disco, mas o arquivo .VCPROJ está referenciando o arquivo em outro lugar.

Você pode “descobrir” isso indo até “include visualização de arquivo” e clicando em cada arquivo de inclusão, por sua vez, até encontrar o que o Visual Studio não consegue encontrar. Você então ADICIONA esse arquivo (como um item existente) e apaga a referência que não pode ser encontrada e está tudo OK.

Uma pergunta válida é: Como o Visual Studio pode até construir se não souber onde estão os arquivos de inclusão?

Achamos que o arquivo .vcproj tem algum caminho relativo para o arquivo problemático em algum lugar que ele não aparece na GUI do Visual Studio, e isso explica por que o projeto será realmente criado mesmo que a visualização em tree das inclusões esteja incorreta.

A resposta aceita me ajudou no caminho certo para descobrir como resolver esse problema para o projeto estragado com o qual eu tive que começar a trabalhar. No entanto, tive que lidar com um número muito grande de headers de inclusão inválidos. Com a saída de debugging detalhada, a remoção causou o congelamento do IDE por 30 segundos durante a saída da debugging de spew, o que tornou o processo muito lento.

Fiquei impaciente e escrevi um script Python rápido e sujo para verificar os arquivos do projeto (Visual Studio 2010) para mim e gerar todos os arquivos ausentes de uma só vez, junto com os filtros em que estão localizados. Você pode encontrá-lo como um Gist aqui: https://gist.github.com/antiuniverse/3825678 (ou este fork que suporta caminhos relativos )

Exemplo:

 D:\...> check_inc.py sdk/src/game/client/swarm_sdk_client.vcxproj [Header Files]: fx_cs_blood.h (cstrike\fx_cs_blood.h) hud_radar.h (cstrike\hud_radar.h) [Game Shared Header Files]: basecsgrenade_projectile.h (..\shared\cstrike\basecsgrenade_projectile.h) fx_cs_shared.h (..\shared\cstrike\fx_cs_shared.h) weapon_flashbang.h (..\shared\cstrike\weapon_flashbang.h) weapon_hegrenade.h (..\shared\cstrike\weapon_hegrenade.h) weapon_ifmsteadycam.h (..\shared\weapon_ifmsteadycam.h) [Source Files\Swarm\GameUI - Embedded\Base GameUI\Headers]: basepaenl.h (swarm\gameui\basepaenl.h) ... 

Código fonte:

 #!/c/Python32/python.exe import sys import os import os.path import xml.etree.ElementTree as ET ns = '{http://schemas.microsoft.com/developer/msbuild/2003}' #Works with relative path also projectFileName = sys.argv[1] if not os.path.isabs(projectFileName): projectFileName = os.path.join(os.getcwd(), projectFileName) filterTree = ET.parse(projectFileName+".filters") filterRoot = filterTree.getroot() filterDict = dict() missingDict = dict() for inc in filterRoot.iter(ns+'ClInclude'): incFileRel = inc.get('Include') incFilter = inc.find(ns+'Filter') if incFileRel != None and incFilter != None: filterDict[incFileRel] = incFilter.text if incFilter.text not in missingDict: missingDict[incFilter.text] = [] projTree = ET.parse(projectFileName) projRoot = projTree.getroot() for inc in projRoot.iter(ns+'ClInclude'): incFileRel = inc.get('Include') if incFileRel != None: incFile = os.path.abspath(os.path.join(os.path.dirname(projectFileName), incFileRel)) if not os.path.exists(incFile): missingDict[filterDict[incFileRel]].append(incFileRel) for (missingGroup, missingList) in missingDict.items(): if len(missingList) > 0: print("["+missingGroup+"]:") for missing in missingList: print(" " + os.path.basename(missing) + " (" + missing + ")") 

Eu apaguei um cpp e alguns arquivos de header da solução (e do disco), mas ainda tinha o problema.

A coisa é, todo arquivo que o compilador usa entra em um arquivo * .tlog em seu diretório temporário. Quando você remove um arquivo, esse arquivo * .tlog não é atualizado. Esse é o arquivo usado por compilações incrementais para verificar se o seu projeto está atualizado.

Edite esse arquivo .tlog manualmente ou limpe seu projeto e reconstrua.

Eu tive um problema semelhante, mas no meu caso não havia arquivos faltando, houve um erro em como o arquivo de saída pdb foi definido: Esqueci o sufixo .pdb (eu descobri com o truque de log de debugging).

Para resolver o problema mudei, no arquivo vxproj, a seguinte linha:

 MyName 

para

 MyName.pdb 

Eu tive esse problema no VS2013 (atualização 5) e pode haver dois motivos para isso, ambos os quais você pode encontrar habilitando a saída de construção “Detalhada” em “Ferramentas” -> “Projetos e soluções” -> “Criar e executar” .

  1. "Forcing recompile of all source files due to missing PDB "..."
    Isso acontece quando você desabilita a saída de informações de debugging nas opções do compilador (em Configurações do projeto: „C / C ++“ -> “Formato de informações de debugging” para “Nenhum” e “Vinculador” -> “Gerar informações de debugging“ para “Não“:) . Se você tiver deixado “C / C ++” -> “Nome do arquivo de database do programa” no padrão (que é “$ (IntDir) vc $ (PlatformToolsetVersion) .pdb”), o VS não encontrará o arquivo devido a um erro ( https : //connect.microsoft.com/VisualStudio/feedback/details/833494/project-with-debug-information-disabled-always-rebuilds ).
    Para consertá-lo, basta limpar o nome do arquivo para “” (campo vazio).

  2. "Forcing rebuild of all source files due to a change in the command line since the last build."
    Este parece ser um bug conhecido VS também ( https://connect.microsoft.com/VisualStudio/feedback/details/833943/forcing-rebuild-of-all-source-files-due-to-a-change-in- a-linha de comando-desde-a-última-build ) e parece ser corrigido em versões mais recentes (mas não VS2013). Eu sabia de nenhuma solução, mas se você fizer, por todos os meios, postá-lo aqui.

Eu não sei se alguém tem esse mesmo problema, mas as propriedades do meu projeto tinham "Configuration Properties" -> C/C++ -> "Debug Information Format" definido como “Nenhum” e quando eu alternei de volta para o padrão ” Banco de Dados de Programas (/ Zi) “, que impediu que o projeto fosse recompilado a cada vez.

Outra solução simples referenciada pelo Visual Studio Forum .

Alterar configuração: menu FerramentasOpçõesProjetos e soluçõesConfigurações do projeto VC ++Modo Solution Explorer para mostrar todos os arquivos .

Então você pode ver todos os arquivos no Solution Explorer.

Encontre os arquivos marcados pelo ícone amarelo e remova-os do projeto.

Está bem.

Eu encontrei esse problema hoje, no entanto, foi um pouco diferente. Eu tinha um projeto DLL CUDA na minha solução. Compilar em uma solução limpa foi OK, mas caso contrário ele falhou e o compilador sempre tratou o projeto DLL do CUDA como não atualizado.

Eu tentei a solução deste post .

Mas não há nenhum arquivo de header ausente na minha solução. Então eu descobri o motivo no meu caso.

Eu mudei o Diretório Intermediário do projeto antes, apesar de não causar problemas. E agora, quando eu mudei o Diretório Intermediário do Projeto CUDA DLL de volta para $ (Configuration) \, tudo funciona de novo.

Eu acho que há algum problema menor entre personalização de compilation CUDA e diretório intermediário não-padrão.

Eu tive problema semelhante e segui as instruções acima (a resposta aceita) para localizar os arquivos ausentes, mas não sem coçar minha cabeça. Aqui está o meu resumo do que fiz. Para serem precisos, esses arquivos não estão faltando, já que eles não são necessários para o projeto construir (pelo menos no meu caso), mas são referências a arquivos que não existem no disco e que não são realmente necessários.

Aqui está a minha história:

  1. No Windows 7, o arquivo está localizado em %ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\% . Existem dois arquivos semelhantes devenv.exe.config.config e devenv.exe.config . Você quer mudar mais tarde.

  2. No Windows 7, você não tem permissão para editar esse arquivo em arquivos de programa. Basta copiá-lo em outro lugar (desktop) alterá-lo e copiá-lo de volta para o local dos arquivos do programa.

  3. Eu estava tentando descobrir como conectar o DebugView ao IDE para ver os arquivos ausentes. Bem, você não precisa fazer nada. Basta executá-lo e capturar todas as mensagens. Certifique-se de que a opção de menu Capture Events esteja selecionada no menu Capture que por padrão deve ser selecionado.

  4. O DebugView NÃO mostrará todos os arquivos perdidos de uma vez (pelo menos não para mim)! Você deve ter o DebugView em execução e executar o projeto no Visual Studio 2010. Ele solicitará a mensagem project out of date do project out of date , selecione Sim para criar e o DebugView mostrará o primeiro arquivo que está faltando ou causando a reconstrução. Abra o arquivo de projeto (não arquivo de solução) no bloco de notas e procure por esse arquivo e excluí-lo. É melhor fechar seu projeto e reabri-lo novamente ao fazer essa exclusão. Repita este processo até que o DebugView não mostre mais nenhum arquivo faltando.

  5. É muito útil definir o filtro de mensagens como não atualizado no botão da barra de ferramentas do DebugView ou na opção EditarFiltrar / Realçar . Dessa forma, as únicas mensagens que ele exibe são aquelas que não têm cadeia de caracteres “atualizada”.

Eu tinha muitos arquivos que eram referências desnecessárias e removê-los todos corrigidos o problema seguindo os passos acima.

Segunda maneira de encontrar todos os arquivos ausentes de uma só vez

Há uma segunda maneira de encontrar esses arquivos de uma só vez, mas envolve (a) controle de origem e (b) integração dele com o Visual Studio 2010. Usando o Visual Studio 2010 , adicione seu projeto a um local desejado ou um local fictício na origem ao controle. Ele tentará include todos os arquivos, incluindo aqueles que não existem no disco, mas referenciados no arquivo do projeto. Vá para o software de controle de origem, como o Perforce , e ele deve marcar esses arquivos que não existem no disco em um esquema de colors diferente. Perforce mostra-os com um bloqueio preto sobre eles. Estas são suas referências ausentes. Agora você tem uma lista de todos eles e pode excluir todos eles de seu arquivo de projeto usando o Bloco de notas e seu projeto não reclamaria de estar desatualizado .

Visual Studio 2013 – “Forçando a recompilation de todos os arquivos de origem devido à falta de PDB”. Liguei a saída de compilation detalhada para localizar o problema: habilitei a saída de construção “Detalhada” em “Ferramentas” → “Projetos e soluções” → “Criar e executar”.

Eu tive vários projetos, todos em C ++, eu defini a opção para sob configurações de projeto: (C / C + + → Formato de Informação de Depuração) para Banco de Dados de Programas (/ Zi) para o projeto problemático. No entanto, isso não impediu o problema desse projeto. O problema veio de um dos outros projetos C ++ na solução.

Eu configurei todos os projetos C ++ para “Banco de Dados do Programa (/ Zi)”. Isso resolveu o problema.

Novamente, o projeto relatando o problema não foi o projeto problemático. Tente definir todos os projetos como “Banco de dados de programas (/ Zi)” para corrigir o problema.

Para mim, foi a presença de um arquivo de header inexistente em “Arquivos de header” dentro do projeto. Depois de remover esta input (clique com o botão direito do mouse em Excluir do Projeto), recompilar pela primeira vez e, em seguida, diretamente

========== Build: 0 sucedido, 0 falhado, 5 atualizado, 0 ignorado ==========

e nenhuma tentativa de reconstrução sem modificação foi feita. Eu acho que é um check-before-build implementado pelo VS2010 (não tenho certeza se documentado, poderia ser) que aciona o sinalizador “AlwaysCreate”.

Se você estiver usando o comando de linha de comando do MSBuild (não o Visual Studio IDE), por exemplo, se você estiver segmentando AppVeyor ou você simplesmente preferir a linha de comando, você pode adicionar essa opção à sua linha de comando do MSBuild:

 /fileLoggerParameters:LogFile=MyLog.log;Append;Verbosity=diagnostic;Encoding=UTF-8 

Conforme documentado aqui (aviso: verbosidade usual do MSDN). Quando a compilation terminar, a pesquisa da string will be compiled no arquivo de log criado durante a compilation, MyLog.log .

Estou usando o Visual Studio 2013 Professional com a Atualização 4, mas não encontrei a resolução com nenhuma das outras sugestões, no entanto, consegui resolver o problema do meu projeto de equipe.

Aqui está o que eu fiz para causar o problema –

  • Criado um novo object de class (Projeto -> Adicionar Classe)
  • Renomeou o arquivo através do Solution Explorer e clicou em yes quando perguntado se eu queria renomear automaticamente todas as referências para corresponder

Aqui está o que eu fiz para resolver o problema –

  • Ir para o Team Explorer Home
  • Clique em Gerenciador de controle de origem
  • Broca na pasta onde todos os arquivos de class / projeto são
  • Encontrou o nome de arquivo ORIGINAL na lista e o excluiu via clique com o botão direito
  • Construir

Se esse for o caso para você, tenha certeza de que está excluindo o arquivo fantasma em vez do arquivo real que deseja manter no projeto.

Eu tive esse problema e achei isso:

http://curlybrace.blogspot.com/2005/11/visual-c-project-continually-out-of.html

Projeto Visual C ++ continuamente desatualizado ( winwlm.h macwin32.h rpcerr.h macname1.h ausente)

Problema:

No Visual C ++ .Net 2003, um dos meus projetos sempre afirmou estar desatualizado, mesmo que nada tenha sido alterado e nenhum erro tenha sido relatado na última compilation.

Abrir o arquivo BuildLog.htm para o projeto correspondente mostrou uma lista de erros PRJ0041 para esses arquivos, nenhum dos quais aparece em meu sistema em qualquer lugar: winwlm.h macwin32.h rpcerr.h macname1.h

Cada erro é algo como isto:

  MyApplication : warning PRJ0041 : Cannot find missing dependency 'macwin32.h' for file 'MyApplication.rc'. 

Seu projeto ainda pode ser construído, mas pode continuar desatualizado até que esse arquivo seja encontrado.

Solução:

Inclua afxres.h vez de resource.h dentro do arquivo .rc do projeto.

O arquivo .rc do projeto continha “#include resource.h”. Como o compilador de resources não honra os blocos #ifdef pré-processador, ele irá separar e tentar localizar os arquivos de inclusão que deveria estar ignorando. Windows.h contém muitos desses blocos. A inclusão de afxres.h, em vez disso, corrigiu os avisos PRJ0041 e eliminou a checkbox de diálogo de erro “O projeto está desatualizado”.

No meu caso, um dos projetos contém vários arquivos IDL. O compilador MIDL gera um arquivo de dados DLL chamado ‘dlldata.c’ para cada um deles, independentemente do nome do arquivo IDL. Isso fez com que o Visual Studio compilasse os arquivos IDL em cada compilation, mesmo sem alterações em nenhum dos arquivos IDL.

A solução é configurar um arquivo de saída exclusivo para cada arquivo IDL (o compilador MIDL sempre gera esse arquivo, mesmo se a opção / dlldata for omitida):

  • Clique com o botão direito do mouse no arquivo IDL
  • Selecione Propriedades – MIDL – Output
  • Digite um nome de arquivo exclusivo para a propriedade DllData File

Passei muitas horas gastas arrancando meu cabelo por causa disso. A saída de compilation não foi consistente; projetos diferentes seriam “não atualizados” por diferentes razões de uma construção para a próxima construção consecutiva. Eu finalmente descobri que o culpado era o DropBox (3.0.4). Eu junit minha pasta de origem de … \ DropBox em minha pasta de projetos (não tenho certeza se este é o motivo), mas DropBox de alguma forma “toca” arquivos durante uma compilation. A synchronization pausada e tudo está consistentemente atualizado.

Existem algumas razões potenciais e – como notado – você precisa primeiro diagnosticar definindo o verbosidade do MSBuild como ‘Diagnóstico’. Na maioria das vezes, o motivo declarado seria auto-explicativo e você seria capaz de agir imediatamente, mas ocasionalmente o MSBuild afirmaria erroneamente que alguns arquivos são modificados e precisam ser copiados.

Se esse for o caso, você precisará desabilitar o tunelamento NTFS ou duplicar sua pasta de saída para um novo local. Aqui está em mais palavras.

Para mim, o problema surgiu em um projeto do WPF em que alguns arquivos tinham a propriedade ‘Build Action’ definida como ‘Resource’ e o ‘Copy to Output Directory’ definido como ‘Copy if newer’. A solução parece ser alterar a propriedade ‘Copy to Output Directory’ para ‘Do not copy’.

msbuild sabe não copiar arquivos ‘Resource’ para a saída – mas ainda triggers uma compilation se eles não estiverem lá. Talvez isso possa ser considerado um bug?

É extremamente útil, com as respostas aqui insinuando como fazer com que msbuild explique por que continua construindo tudo!

Se você alterar os argumentos do Comando de Depuração do projeto, isso também acionará a mensagem de que o projeto precisa ser recriado. Mesmo que o destino em si não seja afetado pelos argumentos de Depuração, as propriedades do projeto foram alteradas. Se você reconstruir, a mensagem deve desaparecer.

Isso aconteceu comigo várias vezes e depois foi embora, antes que eu pudesse descobrir o porquê. No meu caso foi:

Tempo de sistema incorreto na configuração de boot dupla!

Acontece que minha boot dupla com o Ubuntu foi a causa raiz !! Eu tenho preguiça de arrumar o Ubuntu para parar de mexer no meu relógio de hardware. Quando eu entro no Ubuntu, o tempo passa 5 horas para frente.

Por azar, eu construí o projeto uma vez, com a hora errada do sistema, e depois corrigi a hora. Como resultado, todos os arquivos de compilation tinham registros de data e hora incorretos e o VS achava que estavam desatualizados e reconstruíam o projeto.

A maioria dos sistemas de compilation usa registros de data e hora para determinar quando as recriações devem acontecer – o registro de data / hora de qualquer arquivo de saída é verificado na última modificação das dependencies – se alguma das dependencies for mais recente, o destino será recriado.

Isso pode causar problemas se alguma das dependencies de alguma forma obtiver um registro de data e hora inválido, já que é difícil para o registro de data e hora de qualquer saída de compilation exceder o registro de data e hora de um arquivo supostamente criado no futuro: P

Eu tive um problema semelhante com o Visual Studio 2005, e minha solução consistia em cinco projetos na dependência a seguir (primeiro construídos no topo):

 Video_Codec depends on nothing Generic_Graphics depends on Video_Codec SpecificAPI_Graphics depends on Generic_Graphics Engine depends on Specific_Graphics Application depends on Engine. 

Eu estava achando que o projeto Video_Codec queria uma compilation completa, mesmo depois de uma limpeza completa e reconstrução da solução.

Eu consertei isso garantindo que o arquivo de saída pdb do C / C ++ e do linker correspondesse ao local usado pelos outros projetos em funcionamento. Eu também troquei o RTTI.

Outro no Visual Studio 2015 SP3, mas eu encontrei um problema semelhante no Visual Studio 2013 há alguns anos atrás.

Meu problema era que, de alguma forma, um arquivo cpp errado era usado para headers pré-compilados (então eu tinha dois arquivos cpp que criavam os headers pré-compilados). Agora, por que o Visual Studio mudou as flags no cpp errado para ‘criar headers pré-compilados’ sem minha requisição? Eu não tenho idéia, mas aconteceu … talvez algum plugin ou algo assim ???

De qualquer forma, o arquivo cpp errado inclui o arquivo version.h que é alterado em cada compilation. Portanto, o Visual Studio recria todos os headers e, por causa disso, todo o projeto.

Bem, agora está de volta ao comportamento normal.

Os projetos do .NET são sempre recompilados independentemente. Parte disso é manter o IDE atualizado (como o IntelliSense). Lembro-me de fazer essa pergunta em um fórum da Microsoft anos atrás, e essa foi a resposta que me foi dada.